Which third-party requirement applies to your vendor review first?
A procurement or security team that must satisfy several regimes with one vendor review needs to decide which requirement sets the minimum scope before drafting a single questionnaire. Every framework on this page expects you to know and control your suppliers, but the output each one demands differs. DORA requires a register of information on all contractual arrangements for ICT services, PCI DSS requirement 12.8 requires a list of third-party service providers with records of which requirements each one manages, NERC CIP-013 requires a documented supply chain cyber security risk management plan for in-scope BES Cyber Systems, and CMMC flows its obligations down to subcontractors through DFARS 252.204-7012. A review built around the strictest of these outputs will usually cover the shared elements: due diligence, written security terms, incident notice and ongoing monitoring.
Keep one point clear in every vendor file: using a compliant supplier does not transfer your obligations. The PCI DSS SAQ D note to 12.8.1 says that using a PCI DSS compliant TPSP does not make an entity compliant or remove its responsibility for its own compliance, and the same logic runs through the other regimes. Your review should therefore record which controls the vendor operates, which you operate and which are shared, so that each assessor can see your part of the arrangement. Ask each supplier for the evidence it can produce, and confirm with your assessor whether a SOC 2 report, a PCI DSS Attestation of Compliance or a CMMC certificate counts for the scope you need.
Start by mapping which regimes actually apply. Sector, entity type, card data flows, CUI handling and contract language decide the list, and your legal, compliance and contracts teams should confirm it before the questionnaire is final. For a broader view of how these requirements overlap, see the Compliance requirements compared hub and check each vendor against the outputs that your regulator or assessor will actually request.
How each framework defines the vendor obligation
This table compares who must manage vendors under each framework, what the vendor must provide, what the contract or record must contain, how monitoring is expected to work, and what proof results. Read across a row to see one regime's vendor duty, and use the proof column to judge how much weight an outside party places on it.
| Framework and requirement | Who must comply and what they must hold | Contract or record content | Monitoring expectation | Proof produced |
|---|---|---|---|---|
| DORA Article 28(3) | Financial entities in scope of Article 2(1) that use ICT services from third parties | A register of information covering all contractual arrangements for ICT services, provided to the authority on request | Yearly reporting on new arrangements, and timely notice to the authority before planned arrangements supporting critical or important functions | Regulator supervision. No certificate or CPA report is issued |
| NIS2 Article 21(2)(d) | Essential and important entities, as transposed in each member state | Security aspects of the relationship between the entity and its direct suppliers or service providers, documented in the risk-management measures | Set by the entity's risk assessment. Confirm the national transposition law and any sector guidance such as Implementing Regulation 2024/2690 for the relevant service types | Regulator supervision through inspections, security audits, information requests and fines. No certificate |
| PCI DSS 12.8.1 to 12.8.5 | Merchants, processors and service providers that store, process or transmit cardholder data, for the third-party service providers they use | A list of TPSPs, written agreements with security acknowledgments, due diligence before engagement, and records of which requirements each party manages | Monitor each TPSP's PCI DSS compliance status at least every 12 months | Assessor report (ROC) or SAQ with an Attestation of Compliance. Use of a compliant TPSP does not remove the entity's own responsibility |
| SOC 2 CC9.2 | Service organizations that choose a SOC 2 examination, covering vendors and business partners in scope | Risk assessment and management of vendor and business partner risks, as described in the system description | Tested for design in a Type 1 report and for operating effectiveness over a period in a Type 2 report | CPA attestation report. CC9.2 is one criterion examined within the report, not a standalone certificate |
| HIPAA business associate contracts | Covered entities and business associates handling electronic protected health information | Contract must require the business associate to report security incidents it becomes aware of, including breaches of unsecured PHI under 164.410 | Contract terms and the covered entity's own oversight. Confirm how often your counsel expects reviews to occur | Contract on file. HHS states there is no HIPAA certification, so no outside certificate proves this |
| NERC CIP-013-2 R1 | Responsible entities with high or medium impact BES Cyber Systems and their associated EACMS and PACS | Documented supply chain cyber security risk management plans covering vendor risk for those systems | Plan must be implemented and reviewed as the standard requires. Confirm the review cycle with your compliance team and the regional entity | Audit evidence for NERC compliance monitoring. No vendor certificate substitutes for it |
| CMMC flowdown under DFARS 252.204-7012(m) | Prime contractors on defense contracts, who must flow the clause down to subcontractors handling covered defense information | Clause flowed into the subcontract. Subcontractors handling CUI must implement NIST SP 800-171 regardless of CMMC status | Level 2 or Level 3 certification assessment where CMMC applies. Confirm the level required in the contract | Assessor certification from a C3PAOs or DCMA DIBCAC for CMMC levels. Flowdown alone produces no certificate |
How DORA's register of information and NIS2 supply chain security differ
DORA and NIS2 both reach your suppliers, but they ask for different artifacts. DORA Article 28(3) requires a register of information covering all contractual arrangements for ICT services, kept at entity, sub-consolidated and consolidated levels. The register must be provided to the competent authority on request, updated with yearly reporting on new arrangements, and supported by timely notice to the authority before you enter a planned arrangement for a critical or important function. The practical output is a structured inventory of contracts, not a narrative policy. Before you build it, confirm with your supervisor the data fields and format they expect, because the supervisory templates are a matter for the competent authority and the EU supervisory bodies, not for this page to define.
NIS2 takes a different route. Article 21(2)(d) requires supply chain security, which means addressing the security-related aspects of the relationship between each entity and its direct suppliers or service providers. NIS2 does not require a register. For the sectors covered by Commission Implementing Regulation (EU) 2024/2690, the technical and methodological requirements for the Article 21(2) measures are set out in that regulation, so the evidence a regulator expects depends on whether your entity falls in one of those sectors. NIS2 applies from 18 October 2024, while DORA applies from 17 January 2025. Your vendor review should therefore track which obligations are live for your entity today, not only which are coming.
Scope is the condition that decides which duty you carry. DORA applies only to the financial entities listed in Article 2(1), and for financial entities that are also NIS2 essential or important entities, Article 1(2) makes DORA the sector-specific act. NIS2 applies by sector and through each member state's transposition law, so the same supplier may sit inside both regimes for one group. ENISA's mapping of NIS2 to other frameworks, including ISO/IEC 27001:2022, is not a measure of equivalence and does not assess whether a standard covers the regulation's requirements, so a control mapping cannot replace the register. Confirm your classification with your national authority, then build one supplier record that feeds both the register and the NIS2 supply chain review.
Which vendor controls apply to a payments, healthcare or defense supplier
If your organization stores, processes or transmits cardholder data, or could affect the security of that environment, PCI DSS requirement 12.8 applies to every third-party service provider (TPSP) you use. The requirement is about managing that relationship, not outsourcing responsibility. The SAQ D note to 12.8.1 says that using a PCI DSS compliant TPSP does not make your entity compliant or remove your responsibility for your own compliance. The vendor's attestation is one input to your review.
- Maintained list: a current list of each TPSP, with a description of the service it provides.
- Written agreement: a contract that includes security acknowledgments covering the cardholder data the vendor handles.
- Due diligence: a documented review before engagement, and monitoring of the vendor's PCI DSS compliance status at least every 12 months.
- Responsibility matrix: records showing which requirements the vendor manages, which you manage and which are shared.
Check that the vendor's Attestation of Compliance covers the services you actually buy, and confirm with your acquirer or payment brand which validation level and SAQ type apply to you.
Under the HIPAA Security Rule, a covered entity or business associate must have written contracts with business associates that handle electronic protected health information. The contract must require the business associate to report to the covered entity any security incident it becomes aware of, including breaches of unsecured PHI under 164.410. These are contract terms you negotiate, and HIPAA does not provide a certificate that proves the vendor complies.
- Incident reporting clause: the business associate must report security incidents it becomes aware of, as 45 CFR 164.314(a)(2)(i)(C) requires.
- Breach notice content: the vendor must give you the information you need to meet your own breach notification duties under 164.410.
- Safeguard obligations: the contract must require the business associate to implement the administrative, physical and technical safeguards that the Security Rule requires of it.
- Subcontractor flowdown: the vendor must hold its own subcontractors to equivalent terms.
Confirm the notice timing you need, because the contract sets it, and ask the vendor how it will document its own security evaluation. HHS states that it does not endorse private certifications, so treat any vendor certificate as supporting evidence only.
NERC CIP-013-2 requirement R1 requires a documented supply chain cyber security risk management plan for high and medium impact BES Cyber Systems and their associated Electronic Access Control or Monitoring Systems (EACMS) and Physical Access Control Systems (PACS). The standard asks you to plan for supplier risk in procurement, rather than to certify each vendor. Your plan must address the risks you identify, and the vendor must support it.
- Risk plan: a written plan covering vendor risks for in-scope systems, reviewed and approved under your program.
- Procurement terms: contract language that supports the security practices your plan requires, such as vulnerability disclosure and notice of security events.
- Vendor information: evidence the vendor provides on its own practices, which you assess against your plan.
- Scope mapping: a record of which vendors touch high and medium impact systems, and their associated EACMS and PACS.
Confirm your impact categorization with your compliance team first, since it sets which vendors fall under R1. Ask each vendor what security event and vulnerability information it will share, and on what timeline, before you sign.
DFARS 252.204-7012(m) requires the clause to be flowed down into subcontracts that involve covered defense information, so a subcontractor that handles controlled unclassified information must implement NIST SP 800-171 whether or not CMMC applies to that contract yet. The flowdown is a contract obligation, and it reaches your suppliers. Your own assessment of a subcontractor should check the NIST SP 800-171 controls that apply to the information it handles.
- Clause flowdown: the subcontract must include the safeguarding clause wherever covered defense information is involved.
- Safeguarding evidence: the subcontractor must show how it implements NIST SP 800-171 for the systems that handle the information.
- Incident reporting: the subcontract must require the subcontractor to report cyber incidents as the clause requires, so you can meet your own reporting duties.
- Certification status: where CMMC applies to a contract, the CMMC level the subcontractor holds, if any, is a separate fact you should record.
Confirm with your contracting officer which contracts carry the clause and which CMMC level, if any, each subcontract requires.
What changes the vendor review you need
The same vendor can fall under different obligations depending on who you are, what the vendor touches and who else sits in the chain. Use these factors to decide which requirements apply before you build one questionnaire for several regimes.
Regulated entity type
DORA applies to the 20 types of financial entity listed in Article 2(1), from credit institutions to insurers, and NIS2 turns on whether you are classed as essential or important under Articles 3, 32 and 33. Essential entities face ex ante supervision, important entities ex post. Confirm your classification with your national competent authority before you scope the register of information or the supply chain controls.
Contract scope: ICT services or cardholder data
DORA Article 28(3) asks for a register covering all contractual arrangements for ICT services, while PCI DSS 12.8 applies to providers that store, process or transmit cardholder data or could affect the cardholder data environment. A vendor that only hosts your ticketing tool may be out of PCI scope yet still in your DORA register. Map each contract to the service it actually performs before you assign it to a regime.
Vendor's own certifications
A PCI DSS Attestation of Compliance or a SOC 2 report covers only the systems and services its scope names. PCI SSC FAQ 1567 lets a QSA reuse SOC 2 evidence after independently reviewing it, which can reduce duplicated work, but it does not transfer your responsibility. Ask which services and locations each report includes and whether the period still covers the service you buy.
Data type handled by the vendor
Protected health information brings HIPAA business associate contracts that must require the vendor to report security incidents it becomes aware of, including breaches of unsecured PHI. Controlled unclassified information brings NIST SP 800-171 obligations, and cardholder data brings PCI DSS. Name each data type in the contract, because a single vendor handling two types may need two sets of clauses.
Subcontractor chain and flowdown
DFARS 252.204-7012(m) requires the clause to flow down to subcontracts involving covered defense information, so a subcontractor handling CUI must implement NIST SP 800-171 whether or not CMMC applies to it. Your vendor's own subcontractors fall under the same logic. Ask for a list of fourth parties that touch your data, and confirm which flowdown clauses each one has accepted.
How to build one vendor review that satisfies several regimes
This sequence turns one supplier list into a single review file that records what each vendor must prove under each applicable regime, so procurement and security can answer several auditors and regulators from the same evidence. Each regime's specific outputs still need confirmation with the regulator or assessor that oversees it.
Inventory every supplier and contract
Procurement and IT operations build one register of every supplier that touches your systems, data or services, including ICT service providers, cloud hosts, payment processors and managed service providers. Each row links to its contract, the services it provides and the data or systems it can reach. Done means every active contract has a row with an owner, and the team has checked the list against accounts payable and the change log for providers that were added outside procurement.
Map each supplier to the regimes that apply
Legal and compliance staff mark which regimes reach each supplier, such as DORA for financial entities using ICT services, NIS2 supply chain security for in-scope essential or important entities, PCI DSS 12.8 for providers that store, process or transmit cardholder data or affect its environment, SOC 2 CC9.2 where the report is in scope, HIPAA business associate contracts for protected health information, CIP-013 for bulk electric system programs and CMMC flowdown where covered defense information is involved. The output is a matrix of suppliers against regimes, reviewed by the people who can confirm scope with each regulator or assessor.
Split responsibilities for each requirement
For each supplier, the security and business owners record which controls the vendor manages, which you manage and which are shared. This mirrors the split PCI DSS 12.8.5 asks for and gives auditors one place to see where the boundary sits. The check is that no in-scope requirement is left without a named owner on either side, and that the split is signed off by the vendor's contract owner. Note that a compliant provider does not remove your own obligations, as the PCI DSS SAQ D guidance states.
Collect vendor evidence once and reuse it
Security requests one evidence package per supplier: a current SOC 2 report with its scope and period, a PCI DSS Attestation of Compliance where relevant, ISO or other certificates with their scope statements, and a security addendum that requires the provider to report security incidents it becomes aware of and to acknowledge its security responsibilities. Reviewers check the report's scope covers the service you buy and note any exceptions or complementary controls you must run. Where a QSA may reuse SOC evidence only after independent review, keep that review documented.
Add DORA register and CIP-013 plan fields
For suppliers in DORA or CIP-013 scope, extend the register with the fields those regimes need: the contractual arrangement for ICT services, whether it supports a critical or important function, the entity level it sits at and the data needed for the yearly register of information. For CIP-013, attach the supplier to the documented supply chain risk plan for high and medium impact systems. The output is a register that can be produced on request, and a checklist that the regulator or assessor has confirmed the field list matches its expectations.
Run one monitoring cycle at least every 12 months
Assign each supplier a review date no more than 12 months after the last one, which is the monitoring interval PCI DSS 12.8.4 requires for service provider compliance status. Within that cycle, refresh the evidence package, re-check the responsibility split, recheck the incident contact and confirm the supplier still covers the services listed. Done means each record shows a completed review date and a reviewer, and any overdue supplier is escalated to the risk owner.
Record reviews for the auditor
Keep a dated record for each supplier review: the evidence reviewed, the decision made, the open findings, the owner of each finding and any compensating measure accepted. Store the records with the register so one request from an auditor, assessor or competent authority can be answered from the same file. Before the first full cycle, ask each regulator or assessor which records they expect and in what form, because the proof each regime accepts differs and none of them issues a certificate for the vendor review itself.
Common questions about third-party risk requirements
Can one vendor review cover DORA, PCI DSS and SOC 2 at the same time?
Yes, a single vendor review can carry the shared evidence, but it cannot satisfy each regime on its own terms. Build one vendor inventory and one due diligence file, then tag each vendor record with the obligations it triggers: the DORA register of information entry for ICT services, the PCI DSS 12.8 list of third-party service providers and responsibility matrix, and the SOC 2 CC9.2 vendor review. Each regime still needs its own outputs, such as the register format DORA expects and the written acknowledgments PCI DSS requires. Confirm the exact format each regulator or assessor expects before you design the template.
How much effort does the DORA register of information take, and what drives it?
The effort scales with the number of ICT contractual arrangements, how many of them support critical or important functions, and how many systems hold the data needed to fill each entry. Article 28(3) requires the register at entity, sub-consolidated and consolidated levels, yearly reporting on new arrangements, and timely notice to the authority for planned arrangements supporting critical or important functions. Most of the work is in collecting contract data from procurement, finance and business owners, not in the spreadsheet itself. Ask any consultant for a quote that lists the arrangements in scope, the data sources they will pull from, and the number of review cycles included.
Does a SOC 2 report satisfy PCI DSS requirement 12.8?
No, a SOC 2 report does not satisfy requirement 12.8 by itself. Requirement 12.8 asks for a list of third-party service providers, written agreements with security acknowledgments, due diligence before engagement, monitoring of each provider's compliance status at least every 12 months, and a record of which requirements each provider manages. A qualified security assessor cannot rely on a SOC 2 or SOC 3 report alone, but may reuse evidence from those audits after independently reviewing it, which can reduce duplicated evidence work. Your own records still have to show the responsibility split.
What must a business associate agreement contain for HIPAA?
A business associate contract must require the business associate to report security incidents it becomes aware of to the covered entity, including breaches of unsecured protected health information under 45 CFR 164.410. Under 45 CFR 164.314(a), the contract also needs to address the other safeguards the Security Rule requires of the associate, so have counsel check the full text against the current regulation. HHS states that there is no HIPAA certification, so a vendor's certificate does not replace a signed agreement. Ask your counsel to confirm the incident notice timing and the terms for subcontractors that handle the same data.
Can we run the third-party risk program in-house?
Often yes, if your team has the time, the legal support and the security knowledge to review vendor evidence against each regime. An in-house program needs a current vendor inventory, a repeatable due diligence questionnaire, contract clauses that match each framework, and someone who owns the evidence file for every audit. The hard parts are keeping the inventory current as teams add tools and reading vendor reports critically. Consider outside help for a first build of the register or the mapping, then keep the program in-house once the templates and owners are settled.
What should we ask a consultant to include in a fixed-scope quote?
Ask for the written scope before any work starts, including the frameworks covered, the vendors and ICT arrangements in scope, the deliverables and the timeline. A useful quote names each deliverable, such as the register of information, the PCI DSS 12.8 records, the DORA or NIS2 evidence templates and the vendor questionnaire, and states which party gathers the vendor evidence. Also ask what is one-time work and what recurs, such as annual reviews, updates after new vendors are added, and support for regulator or assessor requests. DeployOpen agrees scope, deliverables and timelines in writing before work starts, and most engagements are fixed-scope.
How to confirm your vendor controls in your own environment
This sequence turns the framework requirements into evidence you hold for each vendor: the contract terms, the current assurance report, the register entries, tested incident notice paths and dated monitoring records. Each step ends with a record you can show an auditor, regulator or contracting officer.
Pull and review the vendor contracts
Procurement and legal gather the signed agreements for every vendor that touches your cardholder data, protected health information, ICT services or controlled information. Check each contract for a written security acknowledgment, a clause requiring the vendor to report security incidents to you, a clause on subcontractors and the flowdown of security obligations to them, and a right to receive compliance evidence on request. Where a contract is silent on one of these, record the gap and the owner who will negotiate it. The output is a contract checklist per vendor with each clause marked present, partial or missing.
Confirm current assurance report scope and period
Ask each vendor for its current assurance evidence: a PCI DSS Attestation of Compliance on the official template, a SOC 2 report, or both where the service warrants it. Confirm the report date or period, the systems and locations in scope, and whether the services you buy are inside that scope. For SOC 2 Type 2 reports, check the observation period covers the time you rely on it. For a PCI DSS AOC, confirm it names the service you use. Record any gap between the vendor's scope and your arrangement, because a compliant vendor does not remove your own responsibility for compliance.
Check register fields against ICT arrangements
For DORA, compare each ICT service arrangement in your inventory with the entries in your register of information. Confirm each arrangement has a record, that the fields match the contract (provider identity, service description, locations, subcontracting chain and whether the function is critical or important), and that the register can be produced quickly on request by the competent authority. Flag any arrangement that supports a critical or important function and has no record of planned notice to the authority. The output is a reconciled register with an owner and a review date for each row.
Test incident notice routes to your response team
Run a tabletop or controlled test in which a named vendor contact sends a simulated incident notice through the contractual channel. Measure when the notice reaches your security on-call and incident manager, and whether it reaches the people who handle each regime's reporting obligation, such as GDPR, NIS2, DORA or HIPAA. Compare the time it takes with the clock each applicable regime sets, as set out in the relevant reporting requirements. Record the result, the gaps in routing, and the corrective action. The output is a dated test record showing which notices arrive in time and which need a faster path.
Verify monitoring records are dated within 12 months
For PCI DSS 12.8.4, confirm your team has a dated record that it monitored each third-party service provider's compliance status within the last 12 months. Pull the evidence used for each review, such as the AOC, a SOC 2 report, questionnaire answers or a remediation log, and check the date on each item. Confirm the matrix of which requirements the vendor manages, which you manage and which are shared is current for each provider. The output is a monitoring log in which every provider has a review entry inside the 12-month window, with the owner and the evidence attached.
Confirm accepted evidence with each authority
Write to each regulator, assessor, contracting officer or customer that applies to you and ask which vendor evidence they accept and in what form. Ask a QSA whether it will reuse a vendor's SOC 2 or SOC 3 evidence after its own review, ask a DFARS contracting officer how it expects flowdown evidence, and ask your competent authority how it expects the register to be supplied. Ask NERC-regulated entities how they document supply chain plans under CIP-013-2. Keep the written answers with the vendor file. The output is a per-regime evidence list that your vendor review template follows, so one review can serve several regimes.
When to start the vendor review and what to do first
Start the vendor review with the regime whose obligations bind your entity first, then extend the same supplier file to the others. For a financial entity in scope of DORA, that means the register of information under Article 28(3), which already applies because DORA has applied since 17 January 2025. For an entity in one of NIS2's 18 sectors, the supply chain element of Article 21(2)(d) is the starting point, and you should confirm with your national competent authority how your transposition law treats it. For a merchant or service provider handling cardholder data, the first deliverable is the list of third-party service providers required by PCI DSS requirement 12.8.1, with the responsibility matrix from 12.8.5 built next to it. Confirm which of these applies to you before you build anything, because the deadlines and enforcing bodies differ.
Build one supplier inventory with a field for each regime's question: contract reference, services provided, whether the service touches critical or important functions, data classes handled, incident notification terms, and who manages each control. Record the shared-responsibility split from the start. The SAQ D note to 12.8.1 is explicit that using a PCI DSS compliant provider does not remove your own compliance obligation, and the same principle applies in DORA and NIS2. Add the HIPAA business associate incident reporting term and the CIP-013-2 risk plan fields only where those regimes reach you. Ask each vendor for its current PCI DSS attestation and SOC 2 report, and confirm what period and scope those documents cover.
Keep the review adaptable. PCI DSS v4.0.1 is the only active version, but the PCI SSC ran a request for comments that ended in July 2026 and had announced no release date for a successor as of October 2026. Write the review so that requirement references sit in a mapping table you can update, not in the questionnaire text itself. Do the same with NIS2, where the Commission's January 2026 amendment proposal is still under negotiation. Plan one annual refresh of the supplier file and a review trigger on any change in those texts, and confirm the current status of each with your regulator, assessor or counsel rather than relying on dates from this page.
How DeployOpen helps teams build one vendor review
DeployOpen plans, implements, documents and supports self-hosted open-source platforms inside your own infrastructure, and runs security testing and compliance readiness work alongside them. For third-party and supplier risk requirements, we help you turn several overlapping vendor obligations into one documented review process that you own and can evidence.
How we scope
- Agree in writing which regimes the vendor review must cover, such as DORA, NIS2, PCI DSS 12.8, SOC 2 CC9.2 or HIPAA business associate terms.
- Define which vendors, services and data flows fall in scope, and which ones your own team retains responsibility for.
- Set fixed deliverables and timelines before work starts, so the review has a defined end point and written acceptance criteria.
How we build
- Map each regime's vendor requirement to one shared questionnaire, contract clause set and evidence request, noting where obligations differ.
- Build the vendor inventory and register structure in your environment, covering the fields each regulator or assessor will ask you to produce.
- Test the review workflow against sample vendor records to confirm the evidence trail holds up before it is used for live assessments.
How we hand over
- Document the review procedure, roles, evidence checklist and decision rules so your procurement and security teams can run it without us.
- Provide a control mapping that shows which vendor review step satisfies which requirement, and which items still need your own confirmation.
- Walk your teams through the handover, record open items and agree who owns each recurring task after delivery.
How we support
- Offer ongoing support as a retainer to update the vendor review when contracts, standards or regulator guidance change.
- Schedule periodic reviews of the register, due diligence records and monitoring evidence against the requirements in scope.
- Confirm with your legal, procurement and assessor teams which mappings and interpretations need sign-off before you rely on them.
Sources and further reading
- Regulation (EU) 2022/2554 (DORA), Article 28, EUR-Lex ↗
- NIS2 Article 21 Cybersecurity risk-management measures, EUR-Lex ↗
- PCI DSS v4.0 Self-Assessment Questionnaire D for Service Providers (PCI SSC) ↗
- NERC CIP-013-2, Cyber Security: Supply Chain Risk Management ↗
- eCFR: DFARS 252.204-7012 Safeguarding covered defense information ↗
- PCI SSC FAQ 1567: relying on SOC 2 reports ↗
