Critical Supplier Security Obligations

Page title:    Critical Supplier Security Obligations
Parent:        ISMS Home → 09 · Supplier Security Policy
SCM variant:   isms-all-staff (read — visible to procurement and commercial staff)
               isms-management (read)
               isms-security (full access — CISO maintains)
               isms-it-staff (read)
Page owner:    CISO
Last reviewed: [DATE]
Next review:   Annual — aligned with Supplier Security Policy review
Related pages: 09 · Supplier Security Policy (parent)
               Supplier Security Obligations (standard-tier obligations — 
               read this page first; everything here is in addition to that)
               EV-C → Risk Management → Supplier Assessments (evidence filing)
               Supplier Governance and Business Continuity Oversight (management view)

Who this page applies to

This page applies to suppliers who are designated Critical in our supplier register. A supplier is designated Critical if they meet one or more of the following criteria:

They have access to, or store, Controlled Unclassified Information (CUI) on our behalf, or on behalf of any of our DoD prime contractor customers
They have access to, or store, OFFICIAL or OFFICIAL-SENSITIVE information under any of our DEFSTAN 05-138 contracts
They have privileged access to our production IT systems (server-level access, network device management, cloud administration, database administration, or security tooling)
They deliver a service that forms part of our certified ISMS boundary — meaning their failure would directly impair our ability to maintain our ISO 27001 certification, Cyber Essentials certificate, or CMMC Level 2 self-assessment posture
They are listed as a Critical supplier in the critical supplier register maintained on the Supplier Governance and Business Continuity Oversight page

If you are a supplier and are unsure whether you are designated Critical, contact the CISO at [ciso@organisation.com]. Do not assume you are Standard-tier if your engagement involves production system access or classified data handling — when in doubt, treat yourself as Critical.

The obligations on this page are in addition to the standard-tier obligations on the Supplier Security Obligations page. You must meet everything on the standard-tier page before reading this page. Obligations here either extend a standard-tier requirement to a higher standard, or introduce requirements that do not exist at standard tier.

Why Critical suppliers face higher obligations

The standard-tier obligations protect our information in transit and at rest during typical third-party engagement. Critical-tier obligations exist because a different class of risk applies when a supplier has access to production systems or classified data: a compromise of a Critical supplier does not merely expose a copy of some of our data — it may give an attacker the same access to our systems that the supplier legitimately holds. That is a materially different threat model.

This distinction is recognised explicitly in our compliance frameworks:

DFARS §252.204-7012 and NIST SP 800-171 Rev 2 are the US DoD's requirements for how contractors handling CUI protect it. Critically, DFARS also imposes obligations on us regarding our supply chain — we must ensure that our sub-contractors who handle CUI are operating at an equivalent security level. If a supplier who handles our CUI suffers a breach, we have a 72-hour reporting obligation to the DoD regardless of whether our own systems were touched. That regulatory exposure justifies requiring Critical suppliers to meet the same underlying standard we are held to.

DEFSTAN 05-138 Profile 2 §Supplier Security requires that sub-contractors with OFFICIAL data access are assessed and bound by equivalent security obligations. The contracting authority may inspect our evidence of supplier security compliance at any point during a contract. If we cannot demonstrate that our Critical suppliers meet Profile 1 requirements at minimum, this is a finding against our own DEFSTAN compliance.

ISO 27001 Annex A 5.19–5.22 requires documented supplier security policies, contractual information security requirements, and ongoing monitoring of supplier service delivery. For Critical suppliers, the monitoring obligation is substantially more demanding than for Standard suppliers — an annual questionnaire is the minimum; an independent assessment is the expectation.

Section 1 — Critical-tier certification requirements

1.1 — Mandatory certification

Critical suppliers must hold at least one of the following certifications, with a scope that covers the systems and services used in our engagement. A certification whose scope explicitly excludes the systems you use to handle our CUI, OFFICIAL data, or production access does not satisfy this requirement.

Tier A — Fully satisfies the Critical certification requirement:

ISO 27001:2022 certification
  Issued by an accredited certification body (UKAS-accredited in the UK;
  IAF MLA member body internationally)
  Current certificate — not expired, not suspended
  Scope covers the systems, services, and personnel used in our engagement
  You must provide: certificate number, issuing body, scope statement,
  valid-to date, and the certification body's public lookup URL

CMMC Level 2 certification (C3PAO-assessed)
  Certificate issued by a CMMC Third-Party Assessment Organisation (C3PAO)
  listed on the Cyber AB marketplace (cybermarketplace.net)
  Current certificate (within 3-year assessment cycle)
  For suppliers handling CUI on our behalf under DoD sub-contracts

SOC 2 Type II with Security trust service category
  Report issued by an AICPA-accredited CPA firm
  Current report — period ending within the past 12 months
  Security trust service category must be included
  You must provide a copy of the report or a management summary
  Suppliers with SOC 2 but without ISO 27001 will be assessed by the CISO
  to confirm the SOC 2 controls are sufficient for the access level involved

Tier B — Satisfies the requirement for Critical suppliers with lower-risk access profiles (agreed in advance with the CISO):

Cyber Essentials Plus certification
  Technical verification by a CREST-certified or IASME-licensed assessor
  Current certificate — not expired
  Scope covers the systems used in our engagement
  Cyber Essentials Plus (not Cyber Essentials basic) — the basic self-assessment
  alone does not satisfy Critical-tier requirements

NCSC Cyber Essentials Plus is the minimum acceptable for:
  Suppliers with OFFICIAL access whose engagement is limited to processing
  (not storing) OFFICIAL data, and where our CISO has confirmed in writing
  that Tier B is acceptable for the specific engagement

  It is NOT acceptable for:
  Suppliers who store CUI or OFFICIAL data on their own systems
  Suppliers with privileged access to our production systems
  Suppliers who are sub-contractors on our CMMC-scoped DoD work
  Suppliers listed as Tier 1 in the critical supplier register

Evidence of certification:

You must provide evidence of certification to the CISO at the point of onboarding, at each annual assurance review, and within 10 business days of certification renewal. Evidence means: a copy of the current certificate or report, the certificate number (so we can verify independently), and the scope statement.

We verify all certificates independently — ISO 27001 certificates through the certification body's public register or through the UKAS database; Cyber Essentials through ncsc.gov.uk/cyberessentials/search; CMMC C3PAO certificates through the Cyber AB portal.

A certificate that cannot be independently verified is treated as unverified until verification is possible. We will work with you to resolve verification issues, but we cannot treat an unverifiable certificate as satisfying the requirement.

1.2 — Certification gaps and transition plans

If you do not currently hold a Tier A certification but our engagement requires Critical-tier access, you must:

Provide written confirmation of the certification you are working towards
Provide a specific target date for achieving the certification
Confirm your current certification and security posture in the annual assurance questionnaire (Part 3 of this page)
Agree with our CISO a set of compensating controls that apply during the transition period

A transition plan agreed in writing with the CISO is acceptable for engagements where the Critical designation is new (for example, because the access scope has expanded) or where the supplier is being brought on for the first time. The transition period should not exceed 12 months.

A supplier who reaches the end of an agreed transition period without achieving the target certification, without extending the transition in writing with the CISO, will be suspended from production system access and CUI/OFFICIAL data access until certification is achieved.

Section 2 — CMMC flow-down obligations

This section applies only to suppliers who handle Controlled Unclassified Information (CUI) on our behalf under contracts derived from US Department of Defense work, including sub-contracts from our DoD prime contractor customers. If your engagement does not involve CUI from DoD-related contracts, this section does not apply — confirm with the CISO if unsure.

2.1 — What CMMC flow-down means

DFARS §252.204-7012 requires contractors like us to ensure that our sub-contractors who handle CUI on our behalf are meeting the same NIST SP 800-171 security requirements we are held to. This is not a contractual preference — it is a regulatory obligation. If we cannot demonstrate that our CUI-handling sub-contractors meet these requirements, we are in breach of our own prime contracts.

CMMC flow-down means that if you handle our CUI, you are responsible for:

Implementing and maintaining the NIST SP 800-171 Rev 2 security controls applicable to the CUI you handle — all 110 controls if you handle, store, or process our CUI on your own systems
Conducting an annual self-assessment of your NIST 800-171 implementation and submitting your score to the SPRS database
Having a current Plan of Action and Milestones (POA&M) for any controls that are not yet fully implemented
Having a named senior official affirm the accuracy of your SPRS assessment annually — this is a personal legal obligation for the signatory under the False Claims Act
Reporting cyber incidents affecting our CUI to us within 2 hours of discovery (our obligation to DoD is 72 hours — your 2-hour obligation to us is set to allow us to meet our own clock)
Preserving and providing access to images of any systems affected by a cyber incident, as required by DFARS §252.204-7012(f)

We do not assess whether you are compliant with NIST 800-171 on your own behalf. That is between you, your assessor, and the DoD. We require evidence that you are conducting the assessment and that your SPRS score is current — we do not set a minimum score, but a score materially below 110 will prompt a conversation with our CISO about your POA&M and timeline for remediation.

2.2 — CMMC evidence you must provide

At each annual assurance review, you must provide:

SPRS score and submission record: Your current SPRS score (the number submitted to the Supplier Performance Risk System) and the date of your most recent assessment. We will cross-reference this against the SPRS database if your engagement requires it.

Self-assessment date and methodology: The date your most recent self-assessment was conducted and a brief description of the methodology (Examine, Interview, and Test methods applied — not documentation review alone).

Senior official affirmation: Confirmation that the required annual affirmation has been signed by a senior official of your company, together with the name and role of the signatory. You do not need to provide the signed document itself — confirmation of the signatory's name, role, and the date of signature is sufficient.

POA&M summary: If your SPRS score is below 110, a summary of your open POA&M items: which controls are not yet fully implemented, what the remediation plan is, and target completion dates. You do not need to provide the full POA&M — a summary covering all controls with a score of Not Implemented is sufficient.

Sub-contractor CUI flow: Confirmation of whether you further sub-contract any element of our CUI to additional parties, and if so, what CMMC obligations you have flowed down to those parties.

2.3 — Incident reporting under DFARS

If a cyber incident occurs on your systems that involves, or may have involved, our CUI:

You must call our CISO within 2 hours. This is not an email obligation — telephone contact within 2 hours is required. The CISO's 24/7 contact number is: [CISO mobile number].

Following the call, you must:

Within 24 hours of the incident: - Submit a written incident notification to [ciso@organisation.com] covering: what happened; when it was discovered; which systems were involved; what CUI categories may have been affected; what containment steps you have taken; and the name and contact details of your incident lead

Within 72 hours of the incident: - Preserve a forensic image or equivalent of any affected systems and make it available to us and to our DoD customer on request. Do not remediate affected systems in a way that would destroy evidence until you have confirmed with our CISO that the preservation obligation has been satisfied or waived

Ongoing: - Provide us with daily status updates until the incident is resolved and a post-incident review is complete - Share the findings of your post-incident review with us within 30 days of incident resolution

We will manage the DFARS notification to the DoD on our side. You do not notify DoD directly — notify us, and we will manage the regulatory process. However, if our prime contractor customer requires you to notify them directly, follow their instructions. Contact us immediately if you are uncertain about who to notify.

Section 3 — DEFSTAN supply chain requirements

This section applies to suppliers who handle OFFICIAL or OFFICIAL-SENSITIVE information under our UK Ministry of Defence contracts, or who deliver services that are part of our DEFSTAN 05-138 compliance boundary. The applicable profile (P0, P1, or P2) is specified in your contract schedule.

3.1 — What DEFSTAN requires of our Critical suppliers

DEFSTAN 05-138 Profile 2 §Supplier Security requires that we: - Identify all sub-contractors who have access to OFFICIAL information - Assess those sub-contractors against the applicable DEFSTAN profile - Ensure those sub-contractors are bound by equivalent contractual security obligations - Monitor sub-contractor security performance on an ongoing basis

The contracting authority may ask us to provide evidence of our supply chain security assessments as part of a site assessment or contract renewal review. This means we need evidence of your compliance — not just your assurance that you are compliant.

3.2 — Minimum DEFSTAN profile requirements for Critical suppliers

The minimum profile you must comply with is stated in your contract schedule. Where it is not stated, apply the following defaults:

Access type                              Minimum DEFSTAN profile required
─────────────────────────────────────────────────────────────────────────────────────────
OFFICIAL — transient access only          Profile 0 — all five technical controls:
(viewing, no storage, no processing)      Boundary (firewall), Secure configuration,
                                          User access control, Malware protection,
                                          Patch management

OFFICIAL — storage or processing          Profile 1 — Profile 0 plus:
                                          Documented security procedures,
                                          Personnel security (BPSS for all individuals
                                          with OFFICIAL access),
                                          Incident management procedure,
                                          Change management procedure,
                                          Supplier management for your own sub-contractors

OFFICIAL-SENSITIVE equivalent             Profile 2 — Profile 1 plus:
Higher-sensitivity DEFSTAN work           Vulnerability management (scanning + patching
                                          programme documented and evidenced),
                                          Penetration testing programme,
                                          Cryptography policy (FIPS-equivalent or NCSC CPA),
                                          Active monitoring (SIEM or equivalent),
                                          Enhanced physical security

Specific DEFSTAN contracts with named     Contract schedule defines the specific profile
profile requirement                       and any additional requirements — follow that
                                          document; this table is the default only

3.3 — Personnel security under DEFSTAN

All individuals from your organisation who will have access to OFFICIAL information under our DEFSTAN contracts must hold, at minimum, BPSS screening. This means:

Confirmation of right to work in the UK
Verification of identity (government-issued photo ID)
Verification of employment history (3 years minimum, or since leaving education)
Completion of a basic criminal record check

For OFFICIAL-SENSITIVE or higher: SC clearance (Security Check) is required. The specific clearance requirement for each role will be stated in the DEFSTAN contract schedule.

You must not grant any individual access to our OFFICIAL information until their screening is confirmed. Screening must precede access — not run concurrently with it. We will ask you to confirm the screening status of each named individual in the annual assurance questionnaire, and we will cross-reference against our own access logs.

DEFSTAN personnel notification obligations — your responsibilities:

You must notify our CISO within 24 hours of any of the following events:

Any individual with OFFICIAL access leaving your organisation or ceasing their involvement in our engagement
Any individual's BPSS screening lapsing or being withdrawn
Any SC or DV clearance lapsing, being reviewed, or being revoked for any individual with OFFICIAL access
Any new individual being granted OFFICIAL access on your side — even if you believe our own IT Operations team has been notified separately

Why 24 hours: our DEFSTAN obligation to the contracting authority requires us to notify them of personnel changes within a similar window. Your 24-hour obligation to us is designed to ensure we can meet our own notification clock.

When notifying us of a personnel change, include: - Individual's name and role - Nature of the change (departure, clearance change, new access) - Date the change took effect - Whether any OFFICIAL data in that individual's possession has been recovered or destroyed

3.4 — DEFSTAN evidence package

You must maintain and be able to produce the following evidence on our request. We will review a subset of this evidence at each annual assurance review; we may request the full package if the contracting authority requests a supply chain security inspection.

Evidence required for Profile 0:
  □ Firewall configuration confirming boundary controls are in place
  □ Evidence of current security patches on systems used for OFFICIAL work
    (scan output or patch register covering the past 90 days)
  □ User access register: named individuals with OFFICIAL access
  □ AV coverage report: all systems used for OFFICIAL work
  □ Confirmation that no default credentials are in use on any system
    used for OFFICIAL work

Additional evidence required for Profile 1:
  □ Documented information security policy (approved by senior management,
    current within the past 12 months)
  □ BPSS screening records or summary for all individuals with OFFICIAL access
    (individual serial numbers of screening completions)
  □ Documented incident management procedure
  □ Evidence of at least one security incident review in the past 12 months
    (or confirmation that no incidents occurred)
  □ Documented change management procedure
  □ Evidence that changes to systems used for OFFICIAL work go through a
    documented approval process

Additional evidence required for Profile 2:
  □ Vulnerability scanning reports (past 3 months — authenticated scans)
  □ Patch tracking register showing SLAs from vendor release date
  □ Most recent penetration test report (within the past 12 months)
  □ Evidence of active security monitoring (SIEM or equivalent — log review records)
  □ Encryption specification for OFFICIAL data in transit and at rest
  □ Key management procedure

Section 4 — Technical security requirements for production system access

This section applies to suppliers with privileged access to our production IT systems. This includes but is not limited to: managed service providers; outsourced IT Operations; security monitoring services; cloud platform administrators; network management contractors; database administrators; and any supplier whose personnel hold administrator-equivalent access to any system in our CUI or OFFICIAL scope.

4.1 — Access provisioning for privileged supplier accounts

All privileged supplier access must be provisioned through the same JML process we use for our own staff. The following requirements apply before any privileged access is granted:

Named individual accounts only. Every individual from your organisation who will have privileged access to our systems must have their own named account. Shared administrative accounts are prohibited, including shared service accounts, shared root accounts, and any account that multiple individuals use interchangeably.

BPSS screening completion before access. Every individual with privileged access must have completed BPSS screening before they are granted access. We will cross-reference the screening completion date in your records against the account creation date in our systems — the screening date must precede the creation date. This is the single most commonly tested date relationship in assessments.

PAM-mediated access. All privileged sessions to our systems must be initiated through our Privileged Access Management (PAM) platform. Direct SSH, RDP, or administrative console access without PAM mediation is not permitted. Our IT Operations team will provide you with PAM access instructions during onboarding. Every session is recorded. Session recordings are reviewed monthly as part of EV-F07.

MFA on all accounts. Every account used for privileged access must use multi-factor authentication. For privileged accounts, FIDO2 hardware tokens are required. Software authenticator apps (TOTP) are not acceptable for accounts with administrative access to CUI-scope or OFFICIAL-scope systems.

Access scoped to the minimum required. Supplier accounts will be provisioned with the minimum access needed to deliver the contracted service. We will not grant standing Domain Admin, root, or equivalent wide-scope privileges unless your contract specifically requires it and the CISO has approved the scope in writing. Where broad access is technically required for your contracted service, we will implement time-limited access windows with our IT Operations team present.

4.2 — Operational security requirements for privileged suppliers

Change management compliance. Every change you make to our production systems must be initiated through our RFC (Request for Change) process. The RFC must be raised and approved before the change is made — not as a post-implementation record. Our IT Manager is the Change Advisory Board authority for all changes to CUI-scope and OFFICIAL-scope systems. Emergency changes that must be made outside the RFC process require verbal authorisation from the IT Manager followed by a retrospective RFC within 24 hours.

Session logging and recording. All privileged sessions through our PAM platform are logged and recorded. You consent to this recording by accepting this engagement. Session recordings may be reviewed by our security team and, in the event of an incident, by our regulatory authorities or their delegates.

Maintenance windows. Scheduled maintenance activity must be conducted within the agreed maintenance windows specified in your contract or agreed with our IT Manager. Maintenance outside agreed windows requires our IT Manager approval. If you encounter an emergency situation outside a maintenance window, call our IT Operations team before making any changes.

Supervision for on-site maintenance. Any on-site maintenance work in our Zone 3 (server room and secure network areas) must be conducted with one of our IT Operations engineers present and maintaining visual supervision throughout. This is a DEFSTAN requirement for non-cleared personnel. If your personnel hold SC or DV clearance that we have confirmed and documented, the supervision requirement may be reduced for specific work — confirm with the CISO before assuming supervision is not required.

Post-maintenance verification. Following any maintenance activity affecting our CUI-scope or OFFICIAL-scope systems, you must provide our IT Manager with a written completion report within 24 hours confirming: what was done; which systems were affected; whether the expected outcome was achieved; and whether any unexpected changes were made. We will conduct our own post-maintenance verification within 48 hours.

You must share security alerts with us. If your monitoring of the systems or services you deliver to us detects an anomalous event — a potential intrusion attempt, anomalous access pattern, malware detection, or other indicator of compromise — you must share that alert with our Security Analyst within 4 hours. Do not investigate and resolve silently. We are jointly responsible for the security of our systems; we need the same visibility into threat events that you have.

We will share alerts with you. Our SIEM generates alerts related to activity on our systems. Where an alert relates to actions taken by your personnel or systems, we will share it with you for your awareness. Receiving an alert does not mean we believe you have acted improperly — it means the monitoring system detected something unusual and we are being transparent about it.

Logging standards. All systems you operate on our behalf, or from which your personnel access our systems, must generate security event logs in a format compatible with our SIEM (syslog RFC 5424 or CEF). Log forwarding to our SIEM is a technical requirement for all managed service providers. Our IT Operations team will provide the SIEM endpoint details during onboarding.

Section 5 — Data sovereignty and cloud hosting requirements

5.1 — Data residency for CUI and OFFICIAL information

CUI: Our CUI handling obligations under DFARS require that CUI stored in cloud services resides in the United States or in a jurisdiction with an approved US government cloud certification (FedRAMP Authorized or equivalent). If your service involves storing our CUI in cloud infrastructure, you must confirm:

The specific cloud provider and region(s) used for our CUI
That the cloud service is FedRAMP Authorized (or confirm an alternative approach agreed with our CISO)
That no CUI is replicated, backed up, or cached in regions outside the US without our prior written approval

OFFICIAL information: Our DEFSTAN contracts require that OFFICIAL information is stored within the UK or the EEA unless the contracting authority has approved alternative arrangements in writing. If your service involves storing our OFFICIAL information in cloud infrastructure, confirm the specific cloud provider and region(s) and whether UK or EEA residency is maintained for all data at rest.

5.2 — Encryption key control

For any cloud-hosted service where our CUI or OFFICIAL data is stored: you must demonstrate that you, not the cloud provider, control the encryption keys. This means client-side encryption or customer-managed keys (CMK) in the cloud provider's key management service, with keys that the cloud provider cannot access.

A cloud provider's default server-side encryption (SSE) where the provider holds the keys does not satisfy this requirement. The cloud provider's ability to access or decrypt your data at government request creates a risk to our CUI and OFFICIAL obligations.

If client-side encryption or CMK is not technically feasible for your service and you have an alternative approach that provides equivalent assurance, discuss this with our CISO before onboarding. We need to understand what cryptographic controls are in place and whether they satisfy the FIPS 140-2/3 requirements for CUI.

Section 6 — Sub-contractor and supply chain controls

6.1 — Your supply chain obligations

If you are a Critical supplier to us, you must apply equivalent security obligations to your own sub-contractors who handle our CUI, OFFICIAL data, or have access to the systems you operate on our behalf. "Equivalent" means the same standard you are held to under this page, applied to your sub-contractors by you.

You must:

Maintain a register of your own sub-contractors who have any involvement in our engagement
Assess those sub-contractors' security posture using a process that is at least as rigorous as our annual assurance questionnaire process
Include contractual security obligations in your sub-contractor agreements that flow down the requirements you are bound by
Notify us before adding any new sub-contractor to our engagement and obtain our written approval before granting that sub-contractor access to our systems or data
Notify us immediately if any of your sub-contractors suffers a security incident affecting or potentially affecting our data

6.2 — Software and hardware supply chain

If you supply us with software, firmware, or hardware as part of your service:

Software components must be free from known critical and high-severity vulnerabilities at the time of delivery. Where vulnerabilities exist, they must be disclosed to us and a patch timeline agreed.
You must maintain a Software Bill of Materials (SBOM) for all software you deliver to us and provide it to us on request. An SBOM must include all third-party and open-source components, their versions, and their licence status.
Hardware supplied must be from original manufacturers or authorised distributors. Counterfeit hardware creates unverifiable supply chain risk. You must provide evidence of provenance for any hardware delivered to our CUI-scope or OFFICIAL-scope environments.
Where open-source components are included in software you deliver, you are responsible for monitoring those components for newly disclosed vulnerabilities and notifying us within 5 business days of a Critical or High severity vulnerability in a component you have delivered.

Section 7 — Enhanced incident response obligations

7.1 — Incident notification timelines for Critical suppliers

The standard-tier page establishes Category A, B, and C notification timelines. For Critical suppliers, the following timelines apply in place of (not in addition to) the standard-tier timelines. They are tighter because the proximity of your access to our CUI and production systems creates a tighter regulatory exposure for us.

CRITICAL-TIER INCIDENT NOTIFICATION TIMELINES

Category A — Call our CISO within 1 hour:
  Any confirmed or suspected access to, or exfiltration of, our CUI
  Any confirmed or suspected access to, or exfiltration of, our OFFICIAL information
  Ransomware or destructive malware on any system you use in our engagement
  or that holds our data
  Compromise of any credentials used to access our systems
  Loss or theft of any device holding our data or used to access our systems
  Any event affecting the availability of your service to us where the
  outage exceeds or is expected to exceed your contracted RTO

Category B — Notify our CISO within 4 hours (24/7):
  Any security incident on your systems where our data was not directly affected
  but where investigation is ongoing and impact cannot be ruled out
  Any vulnerability classified Critical severity discovered in systems or
  software you use in our engagement
  Any change to your senior security personnel (CISO, Head of Security,
  equivalent role)

Category C — Notify our CISO within 24 hours (business hours):
  Any completed security incident with confirmed no impact on our data
  Changes to your sub-contractor arrangements affecting our engagement
  Loss of any security certification (ISO 27001, Cyber Essentials Plus, SOC 2)
  or material change to certification scope
  Any regulatory enforcement action, investigation, or fine relating to
  information security or data protection

Escalating events — notify even if investigation is incomplete:
  The above timelines start when you discover the event — not when your
  investigation is complete. If you are still investigating and cannot
  confirm whether our data was affected: notify us anyway. We would
  rather receive a notification that later turns out not to be reportable
  than miss our own regulatory deadline because you were still investigating.

7.2 — Post-incident obligations

Following any Category A or B incident:

Within 48 hours: you must provide a written incident summary including: timeline; affected systems; data involved or potentially involved; containment actions taken; current status; and your named incident lead's contact details.

Within 10 days: you must provide a preliminary root cause analysis identifying the likely cause and initial remediation actions.

Within 30 days: you must provide a post-incident review report covering: confirmed root cause; complete timeline; impact assessment; remediation completed; systemic improvements to prevent recurrence; and whether any changes to your security controls are required.

You must share all three of these documents with our CISO. We will treat them as confidential and use them only for our own incident response, regulatory reporting, and risk management purposes.

Where a post-incident review reveals that the root cause was a control that you had confirmed as implemented in your most recent annual assurance questionnaire: you must notify us of this discrepancy and update your assurance submission within 30 days of the post-incident review completion.

Part 3 — Critical supplier annual assurance questionnaire

This questionnaire supplements and replaces the standard-tier annual self-assessment questionnaire for suppliers designated as Critical. If you are Critical-tier, complete this questionnaire only — do not also complete the standard-tier questionnaire.

Completion deadline: [DATE — typically 31 March each year, or within 30 days of designation as a Critical supplier, whichever is sooner]

Return to: [ciso@organisation.com] with subject line: "Critical Supplier Assurance — [Your company name] — [YYYY]"

This questionnaire will be followed by an assurance review meeting with our CISO within 30 days of submission. The meeting is not optional — it is a condition of maintaining Critical-supplier status.

Questionnaire header

CRITICAL SUPPLIER ANNUAL ASSURANCE — [YYYY]
Submitted by:             [Supplier company name]
Submission date:          [DATE]
Engagement description:   [Brief description — e.g. "Managed infrastructure
                           and security monitoring services — production
                           CUI-scope environment"]
Named contact for this questionnaire:
  Name:                   [Full name]
  Role:                   [Job title — must be CISO or equivalent; not a
                           junior security analyst]
  Email:                  [Email address]
  Phone:                  [Direct number — 24/7 reachable]
Declaration:
  I confirm that the information provided in this questionnaire is accurate
  to the best of my knowledge and belief as of the submission date.
  I confirm that I am authorised by [company name] to make this declaration.
  I understand that providing materially inaccurate information may result
  in immediate suspension of our engagement and referral to the relevant
  regulatory authorities.
  I understand that this questionnaire will be discussed at an in-person or
  video assurance review meeting within 30 days of submission.
Signature:                ___________________________
Date:                     [DATE]

Section A — Certification and standards compliance

A1. Current certification status

  A1.1 ISO 27001 certification:
       ☐ Current  ☐ Expired  ☐ Not held
       Certificate number: _____________________________________________
       Issuing body: __________________________________________________
       Valid to: ______________________________________________________
       Scope statement (or attached): _________________________________
       Does the scope cover all systems used in our engagement? ☐ Yes ☐ No
       If No, describe the out-of-scope systems and compensating approach:
       _______________________________________________________________
       Link for independent verification: ______________________________

  A1.2 ISO 27001 — most recent surveillance or recertification audit:
       Date: ___________ Outcome: ___________________________________
       Nonconformities found: [N] — all closed? ☐ Yes  ☐ No — describe:
       _______________________________________________________________

  A1.3 Cyber Essentials Plus certification:
       ☐ Current  ☐ Expired  ☐ Not held
       Certificate number: _____________________________________________
       Valid to: ______________________________________________________
       Technical assessor: ____________________________________________
       Scope: _________________________________________________________

  A1.4 CMMC self-assessment (if handling our CUI under DoD sub-contracts):
       ☐ Current  ☐ Not required — our engagement does not involve DoD CUI
       SPRS score: [N] / 110
       Assessment date: _______________________________________________
       Senior official affirmation signatory (name and role): ___________
       Affirmation date: ______________________________________________
       POA&M open items: [N] — summary attached: ☐ Yes  ☐ No

  A1.5 SOC 2 Type II:
       ☐ Current  ☐ Not held
       Report period: ________________________________________________
       Trust service categories: _____________________________________
       Auditor: ______________________________________________________
       Is a copy or management summary available to provide to us?
       ☐ Yes  ☐ No — explain: ________________________________________

A2. Standards and regulatory compliance

  A2.1 Has your organisation suffered any regulatory enforcement action,
       investigation, fine, or formal sanction related to information
       security, data protection, or cybersecurity in the past 24 months?
       ☐ Yes — describe: ____________________________________________
       ☐ No

  A2.2 Has any certification been suspended, withdrawn, or significantly
       modified in the past 12 months?
       ☐ Yes — describe: ____________________________________________
       ☐ No

  A2.3 Are you aware of any upcoming change to your certifications that
       might affect the assurances you are providing in this questionnaire?
       ☐ Yes — describe: ____________________________________________
       ☐ No

Section B — ISMS governance and risk management

B1. ISMS governance

  B1.1 Does your organisation have a functioning ISMS managed to ISO 27001
       or equivalent standards?
       ☐ Yes  ☐ No

  B1.2 When was your most recent annual management review of the ISMS?
       Date: __________ Attendees included senior management: ☐ Yes  ☐ No

  B1.3 When was your most recent annual risk assessment?
       Date: ___________
       Did the risk assessment specifically assess risks to our engagement
       and our data? ☐ Yes  ☐ No  ☐ Our general risk assessment covers this

  B1.4 Does your organisation maintain a Plan of Action and Milestones (POA&M)
       for open security findings?
       ☐ Yes  ☐ No
       Open POA&M items: [N]
       Items that directly affect the security of our data or systems: [N]
       Describe the most significant open item:
       _______________________________________________________________

  B1.5 Who is your named CISO or equivalent (the person accountable for
       information security)?
       Name: ________________________________________________________
       Role: ________________________________________________________
       In role since: _______________________________________________
       Has this role changed since your last assurance submission?
       ☐ Yes  ☐ No

B2. Internal audit and assessment

  B2.1 Has your organisation conducted an internal security assessment
       covering the controls relevant to our engagement in the past
       12 months?
       ☐ Yes — date: ________ scope: ________________________________
       ☐ No

  B2.2 Has your organisation conducted a penetration test of the systems
       used in our engagement in the past 12 months?
       ☐ Yes — date: ________ scope: ________________________________
       ☐ No — when is the next test scheduled? _______________________

  B2.3 Has your organisation completed a vulnerability scan of the systems
       used in our engagement in the past 90 days?
       ☐ Yes — date: ________ findings summary: ______________________
       ☐ No — explain: ______________________________________________

Section C — Privileged access and identity controls

C1. Named individual accounts and access management

  C1.1 Provide a complete list of all individuals from your organisation
       who currently have privileged access to our systems. For each
       individual, confirm:

       Name | Role | Systems accessed | Access type | Screening level |
       BPSS date confirmed | PAM access: Yes/No
       ──────────────────────────────────────────────────────────────────
       [Name] | [Role] | [Systems] | [Admin/privileged] | [BPSS/SC/None] |
       [Date] | [Yes/No]
       [continue for all individuals]

  C1.2 Has any individual on this list left your organisation or ceased
       involvement in our engagement since your last assurance submission?
       ☐ Yes — were their accounts deactivated the same day? ☐ Yes  ☐ No
                 describe any gaps: ___________________________________
       ☐ No changes

  C1.3 Has any new individual been granted access to our systems since
       your last assurance submission?
       ☐ Yes — was this notified to our CISO before access was granted?
                ☐ Yes  ☐ No — explain: _______________________________
                Was BPSS screening completed before access was granted?
                ☐ Yes  ☐ No — explain: _______________________________
       ☐ No new individuals

  C1.4 Do all privileged accounts used to access our systems use FIDO2
       hardware tokens for MFA?
       ☐ Yes  ☐ No — describe MFA method in use: _____________________
       ☐ N/A — no privileged access to our systems

C2. Privileged access management

  C2.1 Has your organisation's access to our systems been conducted
       exclusively through our PAM platform in the past 12 months?
       ☐ Yes  ☐ No — describe any exceptions: ________________________

  C2.2 Have there been any instances where your personnel accessed our
       systems outside an agreed maintenance window without prior IT Manager
       authorisation in the past 12 months?
       ☐ Yes — describe and confirm they were reported at the time: ____
       ☐ No

Section D — DEFSTAN personnel security (if applicable)

D1. Completion of this section:
    ☐ This section applies — our engagement involves OFFICIAL information
      under DEFSTAN contracts. Complete all questions below.
    ☐ This section does not apply — our engagement does not involve
      OFFICIAL information under DEFSTAN contracts. Proceed to Section E.

D2. Personnel screening for OFFICIAL access

  D2.1 For each individual with OFFICIAL access (from Section C1.1 above),
       confirm screening status:

       Name | BPSS date completed | SC clearance? | SC expiry |
       UKSV reference (if SC)
       ──────────────────────────────────────────────────────────────────
       [Name] | [Date] | ☐ Yes  ☐ No | [Date/N/A] | [Ref/N/A]
       [continue]

  D2.2 Have any individuals' BPSS screening or security clearances changed
       since your last assurance submission?
       ☐ Yes — describe: ____________________________________________
       Were these changes notified to our CISO within 24 hours? ☐ Yes  ☐ No

  D2.3 Are there any individuals currently with OFFICIAL access whose
       screening or clearance is due to expire within the next 6 months?
       ☐ Yes — describe: ____________________________________________
       ☐ No

D3. DEFSTAN profile compliance

  D3.1 What is the DEFSTAN profile required for your engagement?
       ☐ Profile 0  ☐ Profile 1  ☐ Profile 2  ☐ Not specified (confirm with CISO)

  D3.2 Do you have the evidence package for the required profile available
       for review at our assurance meeting?
       ☐ Yes  ☐ Partial — gaps: ___________________________________
       ☐ No — reason: ______________________________________________

Section E — CMMC flow-down (if applicable)

E1. Completion of this section:
    ☐ This section applies — our engagement involves CUI from DoD
      contracts. Complete all questions below.
    ☐ This section does not apply. Proceed to Section F.

E2. CMMC compliance status

  E2.1 Have you conducted an annual NIST SP 800-171 self-assessment in
       the past 12 months?
       ☐ Yes — assessment date: ___________________________________
       ☐ No — explain: ___________________________________________

  E2.2 What is your current SPRS score?
       Score: [N] / 110
       Date submitted to SPRS: ____________________________________
       Has this score been confirmed in SPRS? ☐ Yes  ☐ No

  E2.3 Has the senior official affirmation been signed for the current
       assessment year?
       ☐ Yes — signatory: _________ Role: _________ Date: __________
       ☐ No — expected date: _____________________________________

  E2.4 How many controls are in your POA&M (not yet fully implemented)?
       Count: [N]
       Controls directly relevant to our engagement: [N]
       Summarise the most significant open items below:
       _______________________________________________________________
       Target closure date for all Critical/High risk items: __________

  E2.5 Do you further sub-contract any handling of our CUI?
       ☐ Yes — have you flowed down CMMC obligations to those sub-contractors?
                ☐ Yes  ☐ No — explain: _____________________________
                Provide sub-contractor list and their SPRS scores: ____
       ☐ No

Section F — Incident response and security events

F1. Incident history — past 12 months

  F1.1 Has your organisation experienced any security incidents in the past
       12 months that affected or may have affected our systems or data?
       ☐ Yes — for each incident:
         Date discovered: ____________ Category (A/B/C): _____________
         Our data affected: ☐ Yes  ☐ No  ☐ Could not be ruled out
         Notified to us within required timelines: ☐ Yes  ☐ No
         Root cause: ________________________________________________
         Remediation: _______________________________________________
       ☐ No

  F1.2 Has your organisation experienced any security incidents in the past
       12 months that did not affect our data but that you are disclosing
       for transparency?
       ☐ Yes — describe: ___________________________________________
       ☐ No

  F1.3 Have you notified us of all security events meeting the notification
       thresholds in Section 7.1 of this document in the past 12 months?
       ☐ Yes  ☐ No — describe any notifications that should have been made:
       _______________________________________________________________

F2. Incident response capability

  F2.1 Do you have a documented security incident response plan?
       ☐ Yes — last reviewed: _____________ last tested: _____________
       ☐ No

  F2.2 Do you have a 24/7 on-call capability for security incidents?
       ☐ Yes — primary contact (name and number): ___________________
       ☐ No — describe after-hours notification approach: ____________

  F2.3 What is your mean time from incident discovery to notification
       of affected clients, based on the past 12 months' experience?
       ☐ Under 1 hour  ☐ 1–4 hours  ☐ 4–24 hours  ☐ Over 24 hours
       ☐ No incidents in past 12 months

Section G — Sub-contractor and supply chain security

G1. Sub-contractors involved in our engagement

  G1.1 List all sub-contractors who have any involvement in the services
       you provide to us, including any who access our data, systems, or
       have an indirect role:

       Sub-contractor | Role | Access type | Certification | CISO-approved?
       ────────────────────────────────────────────────────────────────────
       [Name]         | [Role] | [describe] | [ISO 27001/CE+/None] | ☐ Y ☐ N
       [continue]

  G1.2 Have you flowed down security obligations equivalent to this
       document to all sub-contractors who handle our CUI or OFFICIAL data?
       ☐ Yes  ☐ No — describe the gap: _____________________________
       ☐ N/A — no sub-contractors involved in our engagement

  G1.3 Have you conducted a security assessment of each sub-contractor
       in the past 12 months?
       ☐ Yes  ☐ Partial — [N] not yet assessed — plan: ______________
       ☐ No  ☐ N/A

G2. Software and hardware supply chain

  G2.1 Do you supply us with any software, firmware, or hardware?
       ☐ Yes  ☐ No — skip to Section H

  G2.2 Do you maintain a Software Bill of Materials (SBOM) for software
       you deliver to us?
       ☐ Yes  ☐ No — when can you provide one? _____________________

  G2.3 Are there any known Critical or High severity vulnerabilities in
       software or components you have delivered to us?
       ☐ Yes — describe and confirm you have notified us: ____________
       ☐ No

Section H — Data handling and cloud hosting

H1. Data residency

  H1.1 Where do you store our CUI (if applicable)?
       ☐ US only  ☐ UK only  ☐ EEA only  ☐ US and UK/EEA
       ☐ Other — describe and confirm CISO approval: ________________
       ☐ N/A — we do not store your CUI

  H1.2 Where do you store our OFFICIAL information (if applicable)?
       ☐ UK only  ☐ UK and EEA  ☐ Other — describe: ________________
       ☐ N/A — we do not store OFFICIAL information

  H1.3 Do you control the encryption keys for our data at rest in cloud
       services (client-side encryption or CMK)?
       ☐ Yes — key management platform: ____________________________
       ☐ No — explain: _____________________________________________
       ☐ N/A

H2. Data destruction at engagement end

  H2.1 When our engagement ends, describe the process and timeline for
       securely destroying or returning all copies of our data:
       _______________________________________________________________

  H2.2 Are you able to provide a certificate of destruction within 30 days
       of engagement end?
       ☐ Yes  ☐ No — explain: ______________________________________

Section I — Open issues, exceptions, and additional disclosures

I1. Open exceptions to Critical-tier requirements

  Are there any requirements in Sections 1 through 7 of this document
  that you are currently unable to meet?

  ☐ No — all Critical-tier requirements are currently met

  ☐ Yes — describe each exception below:

    Requirement          | Gap description     | Agreed compensating control
    Section ref          | Current gap         | Agreed by CISO? ☐ Yes ☐ No
    ─────────────────────────────────────────────────────────────────────────
    [Section ref]        | [describe]          | [compensating control]
    [continue]

I2. Additional disclosures

  Is there anything material to the security of our engagement that you
  would like to disclose proactively, that is not covered by the preceding
  questions?

  ☐ Yes — describe: _______________________________________________
  ☐ No

I3. Changes anticipated in the next 12 months

  Are there any significant changes to your organisation, certifications,
  personnel, technology, or security posture expected in the next 12 months
  that we should be aware of?

  ☐ Yes — describe: _______________________________________________
  ☐ No

Section J — Declaration

J1. I declare that:

  (a) The information provided in this questionnaire is accurate and complete
      to the best of my knowledge and belief as of the date of submission.

  (b) I am authorised by [company name] at a level equivalent to CISO or
      above to make this declaration and to commit the organisation to the
      obligations described in the Critical Supplier Security Obligations page.

  (c) I confirm that [company name] is currently meeting all Critical-tier
      security obligations described in the Critical Supplier Security
      Obligations page, subject to the exceptions disclosed in Section I.

  (d) I agree to attend an assurance review meeting with [organisation name]'s
      CISO within 30 days of submitting this questionnaire.

  (e) I understand that providing materially inaccurate information in this
      questionnaire may result in suspension of our engagement, and may be
      referred to relevant regulatory authorities if it affects compliance
      obligations under DFARS or DEFSTAN.

Name:        ___________________________
Job title:   ___________________________  (CISO or equivalent)
Company:     ___________________________
Date:        ___________________________
Signature:   ___________________________

Return to:   [ciso@organisation.com]
Subject:     Critical Supplier Assurance — [Company name] — [YYYY]
Deadline:    [DATE]

Annual assurance review process

This section describes what happens after the questionnaire is received. It is the CISO's operational guide and is visible to isms-security only.

Stage 1 — Questionnaire review (within 10 business days of receipt)

The CISO reviews the questionnaire against the Critical-tier requirements and identifies:

Automatic escalation items — require management notification within 24 hours: - Any incident in Section F not previously notified to us - CMMC SPRS score not current or senior official affirmation not completed - Any DEFSTAN personnel change not notified within 24 hours - Sub-contractors with OFFICIAL or CUI access not previously CISO-approved - Any material inaccuracy compared to our own records (access logs, PAM session records, ITSM change log)

Amber items — require discussion at assurance review: - Any open POA&M items directly relevant to our engagement - Any certification within 90 days of expiry - Any Section I exceptions not previously agreed in writing - Any security incidents in Section F with a response outside the Critical-tier notification timelines

Pass items — no specific follow-up required other than the assurance meeting: - All certifications current and in scope - No incidents or exceptions - Named individuals list consistent with our access logs

Stage 2 — Assurance review meeting (within 30 days of questionnaire receipt)

The assurance review meeting is not a tick-box exercise. It is a structured conversation between our CISO and the supplier's CISO (or equivalent). The meeting has a standard agenda:

CRITICAL SUPPLIER ASSURANCE REVIEW — AGENDA

1. Confirmation of questionnaire accuracy (10 minutes)
   CISO confirms the questionnaire has been reviewed and raises any 
   discrepancies against our own records.

2. Security posture discussion (20 minutes)
   Walk through the supplier's current risk posture: what has changed
   since the last review; what threats are they currently facing;
   what significant incidents or near-misses have occurred.

3. Open items from questionnaire (15 minutes)
   Discuss any amber or red items identified in Stage 1.
   Agree remediation actions and timelines for any gaps.

4. CMMC / DEFSTAN specific (10 minutes — if applicable)
   For CMMC suppliers: SPRS score review; POA&M discussion.
   For DEFSTAN suppliers: evidence package review; personnel status.

5. Upcoming changes (5 minutes)
   Any anticipated changes to technology, personnel, certification,
   or business that we should plan for.

6. Actions and next steps (5 minutes)
   Agree any follow-up evidence to be provided.
   Confirm next annual assurance date.

Meeting notes are filed at: EV-C → Risk Management → Supplier Assessments → [Supplier name] → [YYYY] → Assurance Review Meeting Notes

Stage 3 — Risk rating update and filing (within 5 business days of assurance meeting)

Following the assurance review meeting, the CISO:

Updates the supplier's risk rating in the critical supplier register (Green / Amber / Red)
Files the completed questionnaire and meeting notes at: EV-C → Risk Management → Supplier Assessments → [Supplier name] → [YYYY]
Creates EV-A03 corrective action entries for any items requiring follow-up with agreed owners and deadlines
Updates the Supplier Governance and Business Continuity Oversight page with the new risk rating and assessment date
For any supplier moved to Red: notifies management within 24 hours and initiates the management decision process per the Supplier Governance page

Completed assurance records are retained for 3 years per annual cycle. For DEFSTAN-specific records, retention extends for the duration of the applicable contract plus whatever post-contract period the contract schedule specifies.

Version and review

Version	Date	Prepared by	Approved by	Key changes
1.0	[DATE]	CISO	[Director name]	Initial publication

Page owner: CISO · Review cycle: Annual — aligned with Supplier Security Policy review · SCM: isms-all-staff (read), isms-management (read), isms-it-staff (read), isms-security (full) · Questions: [ciso@organisation.com]