SIAS-TPR-01 Third-party inventory and criticality tiering
- Mandatory
- Yes
- Severity
- Medium
- Applies
- All scopes
- SecurityInspect Verified profiles
- None
Control objective
The applicant knows every third party that touches the in-scope systems or data and how much each one matters, so that its effort goes to the relationships that carry the most risk.
Testable requirement
- 1.The applicant must maintain an inventory of every third party that: stores, processes or transmits in-scope data; has logical or physical access to in-scope systems; hosts, operates or supports in-scope components (for example, cloud, SaaS, managed service and data center providers); or supplies commercial software or services that in-scope systems depend on. Open-source components are covered by SIAS-SDC-05 instead.
- 2.Each entry must record: the service provided; the in-scope data types and their classification; the type of access; the in-scope systems affected; the business owner of the relationship; the contract reference and dates; the criticality tier; and the date of the last security due-diligence review.
- 3.Each third party must be assigned a criticality tier using documented criteria. Tiers: Tier 1, which stores or processes Restricted data, has privileged or network-level access to in-scope systems, or whose failure would stop an in-scope service; Tier 2, which has any other access to in-scope data or systems; and Tier 3, which has no access to in-scope data or systems and low impact.
- 4.The inventory must be updated at onboarding and offboarding and reviewed in full at least every 12 months.
- 5.The applicant should record, for Tier 1 providers, which subcontractors perform the in-scope service, where the provider discloses them.
Applicability and scope
All scopes. Cannot be marked not applicable. SecurityInspect Verified profiles: none.
Pass criteria
- 1.No third party that meets the Tier 1 or Tier 2 criteria is missing from the inventory (A4, M2).
- 2.Every required attribute in requirement 2 is recorded for 100% of Tier 1 and Tier 2 entries.
- 3.Every sampled entry is tiered consistently with the documented criteria.
- 4.A full inventory review was completed within the last 12 months, and every onboarding and offboarding in the look-back period is reflected.
Severity
Medium. Escalation to Critical applies only on the standard escalation triggers in the scoring model (§5.7).
Informative framework mappings
- HIPAA Security Rule
- §164.308(b)(1)
- PCI DSS v4.0.1
- 12.8
- Trust Services Criteria
- CC9.2
- ISO/IEC 27001:2022
- A.5.19
- Theme (SecurityInspect wording)
- knowing and ranking third-party relationships
SIAS-TPR-02 Security due diligence and contractual security terms
- Mandatory
- Yes
- Severity
- High
- Applies
- All scopes
- SecurityInspect Verified profiles
- None
Control objective
Before trusting a third party with in-scope systems or data, the applicant checks its security and binds it to security obligations in writing.
Testable requirement
- 1.Before onboarding a Tier 1 or Tier 2 third party, and at each contract renewal, the applicant must perform security due diligence proportionate to the tier, record the result, and record any residual risk accepted by an accountable owner.
- 2.Due diligence for a Tier 1 third party must include: review of independent evidence where it exists (for example, independent assurance reports or certificates issued to the third party by other bodies, or penetration test summaries); a check that the scope and date of that evidence cover the service the applicant uses; and review of any responsibilities that the evidence assigns to customers, which then feed SIAS-TPR-05. A questionnaire alone is not sufficient for a Tier 1 third party.
- 3.Written agreements with Tier 1 and Tier 2 third parties must include at least: security obligations appropriate to the service; confidentiality; notification to the applicant of security incidents affecting its data or service, within a stated timeframe; limits on the use and disclosure of the applicant's data; return or deletion of data at the end of the service; notice of material subcontracting of the service; and the applicant's right to receive security evidence or to assess the third party, directly or through independent reports.
- 4.Where the applicant is subject to HIPAA and a third party creates, receives, maintains or transmits electronic protected health information on its behalf, a signed business associate agreement must be in place. SIAS checks that the agreement exists and is signed; it does not evaluate its legal sufficiency.
Applicability and scope
All scopes. Cannot be marked not applicable. SecurityInspect Verified profiles: none.
Pass criteria
- 1.Every sampled Tier 1 and Tier 2 third party had due diligence before onboarding or at its latest renewal. A third party onboarded before the applicant's third-party program existed passes this criterion if a retrospective review was completed before the assessment began.
- 2.Due diligence for every sampled Tier 1 third party includes independent evidence, or records why none exists and what alternative steps were taken, and is not based on a questionnaire alone.
- 3.Every sampled contract includes each required term in requirement 3, or is covered by an accepted compensating control.
- 4.Where requirement 4 applies, a signed business associate agreement exists for every such third party.
- 5.Every residual risk was accepted by an accountable owner.
Severity
High. Escalation to Critical applies only on the standard escalation triggers in the scoring model (§5.7).
Informative framework mappings
- HIPAA Security Rule
- §164.308(b)(1), §164.308(b)(3), §164.314(a)
- PCI DSS v4.0.1
- 12.8
- Trust Services Criteria
- CC9.2
- ISO/IEC 27001:2022
- A.5.19, A.5.20, A.5.21
- Theme (SecurityInspect wording)
- checking and contracting for third-party security
SIAS-TPR-03 Ongoing monitoring of critical third parties
- Mandatory
- No
- Severity
- Medium
- Applies
- All scopes
- SecurityInspect Verified profiles
- None
Control objective
The applicant notices when a critical third party's security changes for the worse, and acts on it.
Testable requirement
- 1.Security due diligence must be refreshed at least every 12 months for Tier 1 third parties and at least every 24 months for Tier 2 third parties. Each refresh must obtain current independent evidence where it exists and review any exceptions or qualifications noted in it.
- 2.The applicant must track security incidents, breaches and material changes disclosed by, or publicly reported about, its Tier 1 third parties, and assess their impact on in-scope systems and data.
- 3.Customer responsibilities that a Tier 1 third party's assurance evidence assigns to the applicant must be mapped to the applicant's controls and reviewed at each refresh (see SIAS-TPR-05).
- 4.The applicant should review service performance and the security obligations in the contract with each Tier 1 third party at least every 12 months.
- 5.Issues found must be tracked to resolution or to a documented risk decision by an accountable owner.
Applicability and scope
All scopes. Cannot be marked not applicable. SecurityInspect Verified profiles: none.
Pass criteria
- 1.No Tier 1 refresh is overdue, and every Tier 2 refresh was completed within its interval.
- 2.Every incident involving a Tier 1 third party known from A2 or the applicant's records was assessed for impact.
- 3.A mapping of customer responsibilities exists for every Tier 1 third party whose evidence assigns such responsibilities.
- 4.Every sampled issue was resolved or has a risk decision by an accountable owner.
Severity
Medium. Escalation to Critical applies only on the standard escalation triggers in the scoring model (§5.7).
Informative framework mappings
- HIPAA Security Rule
- §164.308(b)(1)
- PCI DSS v4.0.1
- 12.8
- Trust Services Criteria
- CC9.2
- ISO/IEC 27001:2022
- A.5.22
- Theme (SecurityInspect wording)
- watching critical third parties over time
SIAS-TPR-04 Third-party access control and offboarding
- Mandatory
- Yes
- Severity
- High
- Applies
- Conditional — third parties have logical or physical access to in-scope systems or data
- SecurityInspect Verified profiles
- None
Control objective
Third parties reach in-scope systems and data only as far as their work requires, only while they need to, and always as identifiable individuals.
Testable requirement
- 1.Each individual at a third party who accesses in-scope systems must use a unique named account. Shared interactive third-party accounts are not permitted. System accounts used by third-party integrations are governed by SIAS-IAM-06.
- 2.Third-party access must be approved by the business owner of the relationship, limited to the systems and privileges needed, and time-limited to the contract or engagement term.
- 3.Interactive third-party access must require multi-factor authentication (SIAS-IAM-02) and, for remote administrative access, must use the controlled path in SIAS-NET-02. Vendor remote-support access should be enabled only for the duration of a support session.
- 4.The business owner of the relationship must review third-party accounts and access at least quarterly.
- 5.Access must be removed within the leaver limits in SIAS-IAM-01 (remote and privileged access by the end of the last working day, and all other access within 1 business day) after the engagement ends, the individual leaves the third party, or the access is no longer needed. Contracts must require the third party to tell the applicant promptly when personnel with access leave.
- 6.Access granted to third parties through integrations (API keys, OAuth grants and cross-account cloud roles) must be inventoried, limited to the minimum permissions needed, and revoked at offboarding.
- 7.Third-party physical access to facilities that host in-scope systems must follow SIAS-PHY-01 and SIAS-PHY-05.
Applicability and scope
Conditional — third parties have logical or physical access to in-scope systems or data. It may be marked not applicable only when the SIAS-TPR-01 inventory and A1 to A3 show no such access. SecurityInspect Verified profiles: none.
Pass criteria
- 1.No shared interactive third-party account exists.
- 2.100% of sampled third-party accounts are approved, limited to needed privileges and time-limited.
- 3.Multi-factor authentication is enforced for 100% of interactive third-party accounts.
- 4.Access reviews were completed in every quarter of the look-back period (at least one for an initial assessment with a 90-day look-back).
- 5.100% of sampled offboardings removed access within the limits in requirement 5, and no third-party access was used after its end date.
- 6.Every integration grant to a third party is inventoried and minimally scoped, and none remains for an ended relationship.
Severity
High. Escalate a finding to Critical when an account of a former third party shows activity after offboarding that indicates compromise.
Informative framework mappings
- HIPAA Security Rule
- §164.308(a)(4)(ii)(B)
- PCI DSS v4.0.1
- 8.2, 8.4
- Trust Services Criteria
- CC6.2, CC9.2
- ISO/IEC 27001:2022
- A.5.19, A.5.20
- Theme (SecurityInspect wording)
- limited, identifiable and removable third-party access
SIAS-TPR-05 Shared-responsibility mapping for service providers
- Mandatory
- No
- Severity
- Medium
- Applies
- Conditional — cloud, SaaS or managed service providers operate in-scope components
- SecurityInspect Verified profiles
- None
Control objective
For every in-scope component run by a cloud, SaaS or managed service provider, it is clear who performs each security task, and the applicant's own share has an owner.
Testable requirement
- 1.For each cloud, SaaS or managed service provider that operates in-scope components, the applicant must document a responsibility matrix that shows, for each relevant SIAS domain, which security responsibilities rest with the provider, which with the applicant, and which are shared.
- 2.The matrix must be based on the provider's published responsibility statements, the contract and the provider's assurance evidence (including the customer responsibilities it assigns). It must be reviewed at least every 12 months and whenever the service or provider changes.
- 3.Every applicant-side and shared responsibility must have a named owner and be linked to the SIAS control that implements it.
- 4.Provider-side responsibilities that SIAS controls rely on must be supported by current evidence reviewed under SIAS-TPR-02 or SIAS-TPR-03.
- 5.Applicant-side configuration responsibilities (for example, enabling activity logging, multi-factor authentication, encryption settings, backups and sharing settings in a SaaS tenant) must be implemented. A gap is raised as a finding under the SIAS control that implements the responsibility, not under this control.
Applicability and scope
Conditional — cloud, SaaS or managed service providers operate in-scope components. SecurityInspect Verified profiles: none.
Pass criteria
- 1.A matrix exists for 100% of providers that operate in-scope components.
- 2.Every matrix was reviewed within the last 12 months and after any change of service or provider.
- 3.100% of applicant-side and shared responsibilities have a named owner and a linked SIAS control.
- 4.Every provider-side responsibility relied on is supported by current evidence.
- 5.No applicant-side responsibility found unimplemented by A1 or M3 was missing from the matrix or lacked an owner.
Severity
Medium. Escalation to Critical applies only on the standard escalation triggers in the scoring model (§5.7); for example, a SaaS setting that exposes Restricted data to unauthenticated parties is raised as a Critical finding under the control that covers it.
Informative framework mappings
- HIPAA Security Rule
- §164.308(b)(1)
- PCI DSS v4.0.1
- 12.8, 12.9
- Trust Services Criteria
- CC9.2
- ISO/IEC 27001:2022
- A.5.19, A.5.23
- Theme (SecurityInspect wording)
- clear division of provider security duties
