Index
Third parties are the audience most organisations get wrong. They either show suppliers too much — exposing internal risk assessments, system architecture, and audit findings — or too little, giving them a policy document and assuming compliance follows. The right approach is a curated, purpose-built view that tells suppliers exactly what they must do, gives them the tools to demonstrate it, and generates the evidence your auditor needs to see.---
SCM variant configuration for isms-third-party
The third-party variant is architecturally different from every other audience. All other variants are additive — each group sees a baseline plus additional layers. The third-party variant is restrictive — suppliers see only what you explicitly grant them, and nothing else.
Configure this in Confluence as a separate space or a heavily restricted section, not as a standard SCM variant on your main ISMS space. The reason is containment: if a supplier account is misconfigured, compromised, or over-permissioned, you do not want them accessing your risk register, audit reports, or internal architecture documentation. The safest architecture is a dedicated supplier portal space within your Confluence instance — ISMS-Supplier — with all pages restricted to isms-third-party group members by default, and a controlled cross-space link from your main ISMS space home page pointing suppliers toward it.
If a dedicated space is not feasible, use Confluence page restrictions rather than SCM macros as the primary access control for supplier content. SCM macros hide content visually but do not enforce access control at the data layer — a determined user with space access can sometimes extract macro-hidden content via the Confluence API. Page restrictions enforce access at the server level.
Within the supplier portal space, define two sub-groups in Confluence: isms-third-party-standard (all suppliers) and isms-third-party-critical (suppliers with access to restricted data, production systems, or CUI). Critical suppliers see everything standard suppliers see, plus the SP-02 critical obligations page and the full assurance evidence submission requirements. Use SCM within the portal for this tiering — it is safe here because all users are already restricted to the supplier space.
Onboarding process for supplier Confluence access: procurement or the security team creates the Confluence account, assigns to the appropriate sub-group, sends credentials via a separate channel from the portal URL, and logs the access grant in the supplier register. Access must be revoked within 24 hours of contract end — add this as a standing item on the supplier offboarding checklist.
SP-00 · Supplier welcome and orientation
This page is the entry point for every supplier accessing the portal. It must orient them quickly, set the right tone — collaborative but clear about obligations — and tell them exactly what they need to do in the first week of engagement.
What this space contains. A brief paragraph explaining that this portal is where you access the security requirements you must meet as a supplier or contractor. It contains your security obligations, data handling rules, incident reporting procedure, and the annual assurance process. It does not contain internal security documentation — your own organisation's security posture and controls are managed separately.
Your security contact. The named security contact for supplier queries: name or role title (not personal email — use a shared mailbox such as supplier-security@yourcompany.com), response time commitment (one working day for standard queries, same day for security incidents), and escalation path (CISO contact for urgent matters).
The supplier register. Every organisation with access to this portal must be formally registered in the supplier register. Registration requires: completion of the supplier security profile form (linked); confirmation of the data categories you will access (from the classification scheme on SP-03); confirmation of your Cyber Essentials or equivalent certification status; and signing of the NDA if not already included in your master services agreement. Registration is a precondition of access to our systems and data — this is stated plainly.
Tier assignment. Explain the two tiers briefly: Standard (all suppliers — access to Internal-classified data only, no access to production systems or Restricted data) and Critical (suppliers with access to Restricted data, CUI, or production systems — additional requirements apply and are detailed in SP-02). Tell suppliers which tier they have been assigned and who to contact if they believe the assignment is incorrect.
What happens if requirements are not met. Be explicit: failure to maintain the security standards set out in this portal, or failure to report a security incident within the required timeframe, constitutes a breach of contract and may result in suspension of access and contract termination. This is not a threat — it is the natural consequence stated upfront, which is more professional and legally defensible than raising it for the first time when a breach has occurred.
SP-01 · Standard obligations — all suppliers
Every supplier, regardless of tier, must meet these baseline requirements. They map directly to ISO 27001 Annex A 5.19 and 5.20 (supplier security obligations and supplier agreements), NIST 800-171 3.12.4 (documented security requirements for external systems), and DEFSTAN 05-138 §Supply Chain P1.
Acceptable use of our systems and data. Suppliers with access to our systems or data must: use only the access granted for the specific purpose of their engagement (no exploratory access beyond their scope); never share credentials with colleagues, subcontractors, or anyone else (each individual must have their own account); report to us immediately if they believe their credentials have been compromised; use only approved devices and connections when accessing our systems remotely (company-managed device preferred; if personal device is used, it must have current AV, full-disk encryption, and operating system patching within 14 days of release); and not store our data on personal devices, personal cloud storage, or unapproved platforms.
Data handling minimum requirements. All data received from us must be: classified and labelled correctly (our classification scheme is on SP-03 — your staff must understand it); stored only on systems that meet the minimum security requirements for that classification (encryption at rest for Confidential and above); transmitted only via encrypted channels (TLS 1.2 minimum for data in transit, never via unencrypted email for Confidential or Restricted data); retained only for the duration required by the engagement and our data processing agreement; and deleted or returned at contract end using the process on SP-07.
Subcontractors. You must not subcontract any part of the engagement involving access to our data or systems without our prior written approval. If a subcontractor is approved, the same security obligations apply to them as apply to you — you are responsible for ensuring your subcontractors meet our requirements. This is a direct flow-down of NIST 800-171 3.12.4 and DFARS 252.204-7012 requirements — for US defence contracts, subcontractors handling CUI must meet the same NIST 800-171 requirements as the prime contractor. For DEFSTAN engagements, the MOD expects this flow-down to extend through the entire supply chain.
Minimum technical security baseline. All devices used to access our systems or data must meet the Cyber Essentials technical baseline: current operating system within vendor support; security patches applied within 14 days of release; anti-malware installed and signatures current; full-disk encryption enabled; unique user account (no shared credentials); and MFA enabled for any cloud accounts used in connection with our engagement. If you hold Cyber Essentials certification, that certification demonstrates compliance with this baseline — submit your current certificate via the assurance process on SP-06. If you do not hold Cyber Essentials, you must complete the self-assessment questionnaire on SP-06 annually.
Annual self-assessment. All standard suppliers must complete our annual supplier security self-assessment questionnaire within 30 days of their engagement anniversary. The questionnaire is linked from SP-06. Failure to complete the questionnaire within the required timeframe will result in suspension of access pending completion.
SP-02 · Critical obligations — suppliers with restricted data or production system access
Critical suppliers face materially higher obligations because the consequence of a security failure in their environment directly affects our most sensitive data and systems. The requirements here flow from ISO 27001 Annex A 5.21 (ICT supply chain security) and 5.22 (monitoring and review of supplier services), NIST 800-171 3.12.1–3.12.4, DFARS 252.204-7012 for CUI-handling suppliers, and DEFSTAN 05-138 §Supply Chain P2.
Mandatory security certification. Critical suppliers must hold and maintain at least one of the following certifications — and must submit current certificates annually via SP-06: Cyber Essentials Plus (minimum for UK-based suppliers with access to Confidential data); ISO 27001 certification (required for suppliers handling Restricted data or CUI, or providing cloud services storing our data); SOC 2 Type II (accepted as equivalent to ISO 27001 for US-based suppliers where the audit scope covers the services provided to us). Certification must cover the part of your organisation that processes our data — a group-level certificate that does not cover the relevant subsidiary or business unit does not satisfy this requirement.
For suppliers in our CMMC scope — specifically those who access, process, or store CUI on our behalf or as part of a US government contract — you must also meet the following under DFARS 252.204-7012 and CMMC 2.0: you must implement NIST SP 800-171 Rev 2 to the extent that your systems handle CUI; you must have a written System Security Plan (SSP) covering those systems; you must report cyber incidents to us within 72 hours of discovery (for US DoD contracts, you must also report directly to the DoD Cyber Crime Center); and if you are assessed at CMMC Level 2 or above, you must demonstrate this through a third-party assessment (C3PAO) before handling CUI. Our contract with you specifies the CMMC level required — if you are unsure, contact your contract manager.
DEFSTAN 05-138 supply chain requirements. For suppliers engaged on UK defence contracts where we hold DEFSTAN obligations, you must: hold Cyber Essentials at minimum (Cyber Essentials Plus for suppliers with access to OFFICIAL-SENSITIVE data); provide evidence of compliance with DEFSTAN Level 0 security controls on request; report any cyber security incidents that may affect our defence contract deliverables within 24 hours; and agree to security assessment by us or our appointed representative with 30 days' notice. The MOD may additionally require you to register with the Cyber Security Information Sharing Partnership (CiSP) and to participate in sector-specific threat intelligence sharing — your contract will specify if this applies.
Network and system access controls. Critical suppliers accessing our production systems must: connect only via our approved remote access mechanism (VPN with MFA, or equivalent approved method — credentials and connection instructions are provided separately); never connect from a shared or public network without our VPN; ensure that any device used for remote access to our systems is dedicated to business use and managed by your organisation's IT team (no personal devices for critical supplier remote access); and notify us immediately if a device used for our system access is lost, stolen, or suspected compromised.
Personnel security. For critical suppliers, your personnel with access to our Restricted data or production systems must: have undergone a background check appropriate to the sensitivity of access (for UK defence work, Baseline Personnel Security Standard (BPSS) is the minimum; for personnel with access to SECRET-equivalent information, a higher clearance level applies); sign our NDA or include equivalent confidentiality obligations in their employment contracts; and be individually named in the supplier register — generic "supplier staff" accounts are not permitted. When a named individual leaves your organisation or their role changes such that they no longer require access, you must notify us within one working day so we can revoke their specific access.
Data residency. If you use cloud services to process or store our data, those cloud services must store data within the UK or European Economic Area unless we have provided explicit written approval for other locations. For CUI under US defence contracts, data must be stored in FedRAMP-authorised cloud services unless otherwise specified in your contract. Provide a data residency confirmation in your annual assurance submission.
SP-03 · Data handling and classification rules
This page is the practical reference suppliers need to correctly handle the data they receive from you. It translates your internal classification scheme into supplier-facing instructions.
Our data classification scheme — what suppliers encounter. Public data (freely shareable, no restrictions — most marketing materials and published specifications); Internal data (for business use, not for external publication — routine project communications, non-sensitive technical documentation); Confidential data (restricted to named individuals or teams with a business need — commercially sensitive information, unreleased product specifications, personal data of employees or customers); and Restricted data (our highest sensitivity category, including CUI for US defence contracts, OFFICIAL-SENSITIVE for UK government work, and any data whose exposure would cause significant commercial, legal, or national security harm). Every document and dataset you receive from us will be labelled with one of these classifications — if you receive unlabelled material that appears sensitive, treat it as Confidential and contact us.
Handling requirements per classification. Present these as a table — the most scannable format for practical reference. For each classification: permitted storage locations, encryption requirement at rest, permitted transmission methods, permitted recipients, printing restrictions, and disposal method. For Restricted specifically: encrypted storage mandatory (AES-256 or equivalent); transmission via encrypted channel only (never via email even with TLS — use our approved secure file transfer platform); storage on UK/EEA-based systems only unless explicitly approved; access restricted to named individuals only; physical copies stored in locked storage when not in use; disposal by shredding (cross-cut minimum, micro-cut for most sensitive) with a destruction record retained.
CUI-specific obligations for US defence work. If your engagement involves CUI — Controlled Unclassified Information as defined by the US National Archives CUI Registry — the following additional requirements apply over and above the Restricted classification handling rules: CUI must be marked with the CUI designation on every document and email containing it; CUI must be stored in FIPS 140-2 validated encrypted storage; CUI must not be processed on systems that are also used for non-business purposes; CUI must not leave the country without an export licence where applicable under ITAR or EAR; and any CUI breach — even suspected — must be reported to us within 24 hours and directly to the DoD Cyber Crime Center within 72 hours for DFARS-covered contracts.
UK GDPR and DPA 2018 obligations. If your engagement involves processing personal data on our behalf — employee records, customer data, or any data relating to identified or identifiable natural persons — you are acting as a data processor under UK GDPR Article 28. This means: you must process personal data only on our documented instructions; you must implement appropriate technical and organisational measures to protect personal data; you must assist us in responding to data subject rights requests; you must notify us of any personal data breach within 24 hours of discovery (we have 72 hours from discovery to notify the ICO); you must delete or return all personal data at contract end; and you must not engage a sub-processor without our prior written consent. If you have not yet signed our Data Processing Agreement, contact supplier-security@yourcompany.com — data processing must not begin until the DPA is in place.
SP-04 · Incident reporting
This page is the most time-critical piece of content in the supplier portal. When a supplier has a security incident affecting our data, the quality of this page determines whether they report within 24 hours or discover three weeks later that they were supposed to.
What you must report. Any security event that has or may have affected data or systems belonging to us or processed on our behalf, including: confirmed breach of our data (unauthorised access, exfiltration, corruption, or destruction); suspected breach where you cannot rule out that our data was involved; ransomware or malware infection on systems that store or process our data; lost or stolen device containing our data; accidental disclosure of our data to an unauthorised party; and any cyber incident in your environment that affects the systems or services you provide to us, even if our data is not directly involved. When in doubt, report. We would rather receive a false alarm than discover a breach retrospectively.
Timeframes. The reporting obligation has three tiers: contact us by phone within 24 hours of discovery — do not wait to gather all information, initial notification is time-critical; provide a written incident report within 48 hours covering what happened, what systems and data are involved, what you have done to contain it, and what you are doing next; and provide a full post-incident report within 10 working days covering root cause, remediation actions, and measures taken to prevent recurrence. For DFARS-covered CUI incidents: report to the DoD Cyber Crime Center (DC3) within 72 hours at dc3.mil — this is a separate obligation from reporting to us and is a legal requirement under DFARS 252.204-7012. For UK GDPR personal data breaches: you must notify us within 24 hours so we can fulfil our 72-hour obligation to the ICO. Breach of these reporting timelines is itself a regulatory violation — we cannot report to the ICO or DoD if we do not know the incident has occurred.
How to report. Primary: call supplier-security@yourcompany.com and phone number (available 24/7). Do not use a standard project email thread for incident reporting — use this channel only. Include in your initial report: your organisation name and contract reference; the name and contact details of your security contact; when you discovered the incident; what you know so far about what happened; whether you believe any of our data is involved; and what immediate containment steps you have taken. Do not try to investigate or remediate before notifying us — contain the incident first (isolate affected systems, stop the bleeding) and notify immediately. Independent investigation by the supplier before notification to us has caused significant delays to incident response in the past.
What happens after you report. We will acknowledge your report within two hours during business hours, four hours outside business hours. We will assign an incident coordinator who will be your point of contact throughout the response. We may request forensic access to affected systems — you must provide this access within 48 hours of our request. We will manage communications with regulators (ICO, DoD) but require your full cooperation and prompt responses to our information requests. Incident response is a shared process — your cooperation determines the outcome.
SP-05 · On-site security rules
For contractors who work at your premises, the physical security rules they must follow are different from those of employees — they do not have the background context of induction training, they may not know the physical layout, and their devices are not under your IT management.
Site access procedure. All contractor and supplier staff must: sign in at reception on every visit and receive a visitor badge — this badge must be worn visibly at all times on site; never use an access card or PIN belonging to someone else; never follow another person through a controlled door without presenting their own credentials (tailgating is a reportable security incident even if unintentional — if you see tailgating, report it to the security desk); not access areas beyond those required for their specific work without prior approval; and sign out at reception on departure, returning their visitor badge. Regular contractors who have been issued a permanent access card (distinct from a visitor badge) must report its loss immediately — call the security contact number, do not wait until the next business day.
Device policy on site. Contractor-owned laptops may be connected to our guest Wi-Fi network only — not to any wired network port without specific IT approval. Contractor laptops must: have current anti-malware installed and active; be running a supported operating system with current patches; have full-disk encryption enabled; and not be used to store our Confidential or Restricted data on local storage unless specifically approved and the device meets our secure device requirements. Personal mobile phones may be used on site for personal communications; they must not be connected to our corporate network, and photography is prohibited in all secure areas (server rooms, secure workrooms, areas marked with signage). USB drives and external storage devices may not be connected to our equipment. If you need to transfer files between your device and our systems, use the approved file transfer method — contact IT for guidance.
Prohibited activities on site. The following are prohibited without exception: accessing our systems or data beyond the scope of your engagement; taking photographs in any restricted area or of any screen displaying our data; connecting any device to our network without IT approval; removing any physical documents, storage media, or equipment without a signed removal authorisation form; and discussing the details of your work with other contractors or visitors on site. Breach of these rules will result in immediate suspension of site access and may result in contract termination.
SP-06 · Assurance and evidence submission
This page is where the supplier compliance cycle closes. It tells suppliers what evidence they must provide, how to provide it, and what the consequence is of not providing it.
Standard supplier annual self-assessment. All standard suppliers complete our annual security questionnaire covering: the security measures in place for devices used to access our systems; how your organisation manages user accounts and access control; your patching and AV update practices; how you protect data at rest and in transit; your incident reporting capability; and whether your organisation holds any security certification. The questionnaire is [linked here — attach the questionnaire as a Confluence page or embed a form]. Completion takes approximately 30 minutes. Responses are reviewed by our security team within 10 working days. Where responses indicate gaps against our standard requirements, we will contact you to discuss remediation with a defined timeline.
Critical supplier annual assurance pack. Critical suppliers must provide annually: a current copy of your Cyber Essentials, Cyber Essentials Plus, or ISO 27001 certificate covering the relevant scope (submission via the security inbox with your contract reference); a completed version of our critical supplier security questionnaire [linked] covering system architecture, data handling practices, incident response capability, and personnel security measures; confirmation of data residency for any cloud services used to process our data; a summary of any significant security incidents in the past 12 months that affected or may have affected systems or data in scope for our engagement; and, for CMMC-scoped suppliers, your current SPRS score and the date of your most recent self-assessment or C3PAO assessment. All documents submitted are treated as Confidential and used only for supplier assurance purposes.
Certificate submission. Upload your security certificates and the completed questionnaire to [the secure submission method — Confluence file attachment, encrypted email, or a secure document portal]. Include your organisation name and our contract reference on all submissions. We will acknowledge receipt within two working days and will notify you if any documents are missing or expired. Your certification status is updated in our supplier register and is reviewed as part of each contract renewal decision.
Right to audit. Your contract includes a right-to-audit clause. We may conduct, or commission an independent third party to conduct, a security assessment of the systems and processes within your engagement scope. We will provide 30 days' notice for a planned audit. You must provide reasonable access to systems, documentation, and personnel necessary to complete the assessment. Audit findings will be shared with you and you will have 10 working days to provide a written remediation plan for any high-severity findings. The right-to-audit clause is not a routine commercial negotiation point — it is a requirement of ISO 27001 Annex A 5.22 and NIST 800-171 3.12.1, and its absence from a contract makes meaningful supplier assurance impossible.
SP-07 · Exit and offboarding
Contract end is the moment of highest data exposure risk in a supplier relationship. This page defines exactly what must happen and in what sequence.
Data return and deletion. Within five working days of contract end: return to us (via the approved secure transfer method) any data we provided during the engagement, or confirm in writing that all copies have been deleted; provide written confirmation that no copies of our Confidential or Restricted data remain in your possession, on your systems, or with any of your subcontractors; for Restricted data and CUI, provide a destruction record specifying the deletion method (cryptographic erasure for encrypted storage, NCSC-approved overwriting for HDDs, physical destruction for SSDs and removable media). If your organisation uses cloud services to process our data, the deletion must extend to cloud storage including backups — provide written confirmation from your cloud provider or a screenshot of the deletion confirmation.
Access revocation. On the contract end date (or earlier if our engagement concludes before the contract term): we will disable all individual accounts with access to our systems — you do not need to take any action on this, but you should confirm with your staff that their access has ended; you must revoke any API keys, service account credentials, or certificates issued during the engagement from your side; if you hold any of our SSH keys, shared secrets, or configuration credentials, return them to us or confirm destruction; and notify us of any accounts or credentials you are aware of that we may not have on our records.
Physical equipment and materials. Return all physical items provided by us: access cards or tokens, physical documents or media containing our data, any equipment loaned for the engagement. For any physical documents in your possession containing our Confidential or Restricted data: shred using a cross-cut shredder at minimum and provide a written confirmation; do not simply dispose of documents in a recycling bin or general waste stream. If in doubt about the classification of a document, treat it as Confidential.
Ongoing confidentiality obligations. The confidentiality obligations in your NDA and contract do not end when the contract ends. Your organisation and your personnel who worked on our engagement remain bound by those obligations for the period specified in your contract — typically two to five years, sometimes indefinitely for trade secrets. This means: you may not disclose the existence of our engagement, its scope, or any information you encountered to any third party; you may not use information obtained during the engagement for any purpose other than fulfilling the contract; and you must notify us immediately if you receive a legal request to disclose information relating to our engagement (a court order, regulatory enquiry, or discovery request). Your personnel who leave your organisation after the engagement take these obligations with them as individuals.
The framework flow-down requirements in full
The supplier security requirements across your three primary frameworks create overlapping but distinct obligations on your suppliers. Understanding exactly what each framework demands helps you set proportionate requirements and explain them to suppliers who challenge them.
ISO 27001 Annex A controls 5.19 through 5.22 are the four supplier-facing controls in the 2022 edition. Control 5.19 requires that security requirements for accessing your assets are identified and agreed with each supplier — this is your supplier security questionnaire and the security schedule in the contract. Control 5.20 requires that those requirements be formally documented in supplier agreements — this is the security schedule, NDA, and data processing agreement. Control 5.21 addresses ICT supply chain security specifically — it requires you to assess and manage information security risks associated with your ICT product and service supply chain, including hardware and software components, not just the direct supplier relationship. This is where software bills of materials (SBOM) and component provenance are increasingly relevant for defence contracts. Control 5.22 requires that you regularly monitor, review, and audit supplier service delivery against your security requirements — this is the annual assurance review, the right-to-audit clause, and the quarterly supplier register review.
NIST 800-171 control 3.12.4 is the primary supply chain control: "Periodically assess the security controls in organisational systems hosting external system connections." In practice this requires: documented security requirements for each external system connection (which in a supplier context means each supplier's connection to your network or systems); periodic assessment of whether those requirements are being met; and where requirements are not met, documented remediation plans. For CMMC-scoped engagements, 3.12.4 also carries the flow-down obligation — your suppliers who access or process CUI must implement the same NIST 800-171 requirements that you do. This is the requirement that makes your supplier security questionnaire a legal document rather than a best-practice exercise.
DFARS 252.204-7012 — the primary CMMC driver for supplier obligations — requires that when a contractor processes, stores, or transmits CUI, their subcontractors who also handle CUI must meet the same NIST 800-171 requirements. The contracting officer may require evidence of subcontractor compliance. The 72-hour incident reporting obligation to DC3 applies to all subcontractors handling CUI, not just the prime contractor. This creates a chain of obligation that you as a prime or sub-prime must flow down to your own suppliers.
DEFSTAN 05-138 §Supply Chain requirements operate similarly. The standard expects prime contractors and their subcontractors to implement cyber security controls proportionate to the sensitivity of the information they handle. The MOD's cyber security model requires that contracts flowing information classified at OFFICIAL or above include security requirements on subcontractors — typically at minimum Cyber Essentials, with higher requirements for OFFICIAL-SENSITIVE data. The expectation is that you assess your subcontractors' security posture before granting them access to information received under a defence contract, and that you monitor their compliance throughout the contract. Incident reporting obligations flow down — if your subcontractor has a cyber incident affecting MOD programme information, you are responsible for notifying the MOD even if the incident occurred in the subcontractor's environment.
Now let me generate the downloadable supplier security pack — a structured workbook containing the annual self-assessment questionnaire, the critical supplier assurance template, and the supplier register format.The workbook has five sheets, colour-coded in coral throughout to distinguish it visually from your other ISMS workbooks:
Supplier Register — the live operational register with all 20 fields including CUI access flag, DEFSTAN scope flag, certification expiry dates, DPA and NDA status, and Confluence access grant/revoke dates. The three sample rows show Standard and Critical tier examples. Critical suppliers are highlighted in coral, Standard in teal.
Standard SAQ — 26 questions across six domains (Access Control, Devices, Network, Data Handling, Incident Response, Personnel) covering the baseline obligations every supplier must meet annually. Answer and Evidence columns are pre-formatted for supplier completion. Framework references appear in blue on each question row.
Critical Supplier Assurance — 24 additional questions across six sections including certification evidence, system architecture, CUI-specific controls, incident response capability, personnel security, and physical security. Includes an evidence submission checklist requiring certificate attachments. This is the document a C3PAO assessor or DEFSTAN auditor will ask to see as evidence of supply chain assurance.
Framework Flow-Down — 12 obligation areas mapped across ISO 27001 Annex A, NIST 800-171, CMMC, and DEFSTAN 05-138 with a direct link to the corresponding supplier portal page. Use this when a supplier challenges why a requirement exists — the control reference is the answer.
How to Use — operational guidance including retention periods and the Confluence integration note connecting this workbook to EV-D16 and EV-D17 in your evidence register.
The three supplier security failures that cause the most compliance damage
Having built the full supplier content architecture, the patterns that most commonly surface in audits and incidents are worth naming directly.
The first is the undiscovered subcontractor. A critical supplier engages a cloud platform or sub-processor that accesses your data without your knowledge or formal approval. ISO 27001 A.5.21, NIST 3.12.4, and DFARS all require this to be controlled. The Critical Supplier Assurance question CSA-H04 specifically surfaces this — a supplier who cannot answer that question cleanly is a supplier whose subcontractor chain is not under governance.
The second is the late incident report. A supplier discovers a breach on a Friday afternoon, waits until Monday to "gather all the information," and tells you on Tuesday. You have now missed your ICO 72-hour window through no action of your own. The SP-04 page exists to prevent this — but suppliers who have not read and acknowledged it before an incident occurs will default to their own judgment about timing. Build the 24-hour obligation into every contract security schedule, and test it: include incident reporting as a scenario in your annual supplier assurance review.
The third is the lapsed certificate gap. A critical supplier's Cyber Essentials certificate expires in March. Your annual assurance review is in September. For six months you are carrying a supplier who no longer meets your baseline requirement and who may no longer meet your DEFSTAN contract obligations. The supplier register's Next Assurance Due Date column and the 60-day expiry alert on the certificate inventory (EV-D30) together close this gap — but only if someone is actively monitoring them. Assign a named owner to the supplier register and put the monthly review on their calendar.