Supplier Governance and Business Continuity Oversight
Confluence page header
Page title: Supplier Governance and Business Continuity Oversight
Parent: ISMS Home
SCM variant: isms-management (primary)
isms-security (full access — CISO maintains)
isms-all-staff: NOT visible
isms-it-staff: NOT visible
Page owner: CISO (supplier security) + [Operations Director] (BCM)
Last reviewed: [DATE]
Next review: [DATE + 12 months — reviewed at annual management review]
Why these two domains belong together for management
Supplier security and business continuity are presented on this page together because they share a common management accountability characteristic that distinguishes them from other ISMS domains: both require decisions that cannot be delegated to the CISO or the IT team, and both carry consequences that extend beyond the organisation's own systems.
A supplier security failure is not an internal matter — it is a third-party event that may have triggered your DFARS 72-hour reporting obligation, your DEFSTAN 24-hour notification, and your ICO personal data breach reporting, none of which the CISO can initiate without your awareness and direction. A business continuity failure is not a technical recovery task — it is a commercial crisis that requires management to make decisions about customer communication, contractual obligations, and resource deployment that the IT Manager cannot make unilaterally.
Both domains also share an uncomfortable truth: the frequency with which organisations discover their supplier security and BCM governance is inadequate is highest at exactly the moment when they most need it to work. This page is designed to prevent that discovery from happening during an incident.
Section 1 — Critical supplier risk summary
Updated quarterly by the CISO. This section provides the management-level view of the organisation's supply chain security posture.
What this section covers
The organisation relies on third-party suppliers for services that form part of the ISMS boundary — cloud hosting, email gateway, EDR platform, backup services, identity management, and in some cases personnel who access CUI-scope systems. Each of these relationships introduces risk that cannot be entirely controlled through our own security controls.
This section summarises the risk posture of the supplier relationships that matter most — defined as those where a supplier failure, breach, or compromise would: expose CUI to an unauthorised party; trigger a mandatory regulatory notification; affect our ability to deliver on a DEFSTAN or DoD contract; or disrupt operations for more than four hours.
Critical supplier register
This register is maintained by the CISO and updated when supplier relationships change, when a supplier incident occurs, or when an assessment reveals a change in risk rating. The full supplier assessments are filed at EV-C → Risk Management → Supplier Assessments.
CRITICAL SUPPLIER REGISTER — as of [DATE]
Risk levels: Green (within appetite) | Amber (approaching threshold) |
Red (exceeds appetite — management attention required)
Supplier name | Service provided | CUI/OFFICIAL access | Risk level | Last assessed | Next assessment | Status
─────────────────────────────────────────────────────────────────────────────────────────────────────────────
[Supplier A] | Cloud hosting (CUI-scope servers) | Yes — CUI | Amber | [Date] | [Date] | Under review
[Supplier B] | Email gateway | Transient only | Green | [Date] | [Date] | Current
[Supplier C] | EDR/MDR service | Telemetry only | Green | [Date] | [Date] | Current
[Supplier D] | Backup and recovery | Yes — CUI | Green | [Date] | [Date] | Current
[Supplier E] | Managed IT (sub-contractor) | Yes — CUI + OFFICIAL | Amber | [Date] | [Date] | Pending re-assessment
[Supplier F] | Software development | No | Green | [Date] | [Date] | Current
[Add rows as applicable]
Quarterly CISO commentary — supplier posture
[DATE] — Q[N] [YYYY]
[This commentary is written fresh each quarter. The example below illustrates the expected depth and tone.]
The critical supplier register contains [N] suppliers assessed as Amber or above this quarter, compared to [N] in the prior quarter.
The most significant change is [Supplier E], which remains at Amber following their disclosure in [month] that they experienced a ransomware incident affecting their internal systems. Our assessment, completed on [date], confirmed that no CUI or OFFICIAL data held on our behalf was accessed or exfiltrated. However, [Supplier E]'s incident response process revealed gaps in their own ISMS — specifically, their privileged access management did not match what they had represented in their security questionnaire. A revised contractual schedule has been negotiated and is awaiting their signature. Until that signature is received and independently verified, [Supplier E] remains at Amber.
[Supplier A] remains Amber due to the ongoing DEFSTAN Profile 2 assessment requirement. [Supplier A] processes data on behalf of our MOD contract, and our contracting authority has indicated they expect us to have assessed [Supplier A] against Profile 1 requirements by [date]. That assessment is scheduled and we expect to move them to Green by Q[N+1].
No supplier currently sits at Red. If any supplier were to reach Red, management would be notified within 24 hours regardless of the quarterly cycle.
How the supplier risk assessment works
Management should understand what the risk ratings mean and how they are derived, so that management decisions about supplier relationships are made on a consistent basis.
Every critical supplier is assessed against a security questionnaire that covers the five Cyber Essentials technical domains plus supply chain-specific questions on access controls, incident notification, and data handling. For suppliers handling CUI, the questionnaire also covers NIST SP 800-171 compliance. For suppliers handling OFFICIAL information for our DEFSTAN contracts, the questionnaire covers DEFSTAN Profile 1 minimum requirements.
The assessment produces a risk rating: Green if the supplier meets the minimum requirements for their access level; Amber if there are identified gaps with an agreed remediation timeline; Red if there are material unmitigated gaps with no agreed remediation plan or if a supplier incident has occurred without adequate resolution.
An Amber rating does not automatically mean the supplier relationship should be terminated. It means management is aware that the relationship carries elevated risk, that the CISO is actively managing remediation, and that management may need to make decisions if remediation does not progress.
A Red rating requires a management decision within 30 days: accelerate remediation with specific commitments, reduce the scope of the supplier's access to CUI or OFFICIAL data, or terminate the relationship.
Supplier incidents in the past 12 months
Every supplier security incident that affected or potentially affected our CUI or OFFICIAL data is summarised here.
[DATE] — [Supplier name] ransomware incident
Notified to us: [DATE] ([N] days after their detection)
Our CUI affected: No — confirmed by [method]
OFFICIAL data affected: No — confirmed by [method]
Regulatory notification required: No
Action taken: [summarise]
Current status: [resolved / under monitoring / contractual change in progress]
[DATE] — [Supplier name] unauthorised access to management systems
[same format]
[Or: "No supplier security incidents affecting our CUI or OFFICIAL data in the past 12 months."]
What management must decide about suppliers
Routine decisions — managed by CISO without management involvement: - Scheduling and conducting supplier security assessments - Issuing security questionnaires and reviewing responses - Moving a supplier from Green to Amber when gaps are identified - Negotiating revised security schedules in existing contracts
Management decisions required:
TRIGGER: Supplier moves to Red
Required within 30 days:
Decision A: Accept elevated risk for [period] while remediation is enforced
(requires formal risk acceptance — CISO prepares for management sign-off)
Decision B: Restrict supplier's access to CUI/OFFICIAL pending remediation
(CISO proposes; operations/commercial director approves)
Decision C: Terminate the supplier relationship
(Commercial director decision with CISO and CISO security input)
TRIGGER: Supplier incident confirms CUI exposure
Required same day:
Decision: Authorise regulatory notifications (DFARS, ICO, DEFSTAN)
Authority: Director-level — CISO cannot initiate without Director awareness
TRIGGER: New contract requires a supplier to access CUI or OFFICIAL data
Required before the supplier is granted access:
Decision: Confirm the supplier has been assessed and rated Green
OR accept interim access under specific compensating controls
Authority: Commercial director + CISO co-approval
TRIGGER: A supplier relationship is due for renewal where security
terms have not been updated in more than 3 years
Required before renewal:
Decision: Approve updated security schedule in the renewed contract
Authority: Procurement / commercial director + CISO review
Section 2 — Contract security obligations
The security obligations that must appear in supplier contracts are not technical preferences — they are the mechanism by which the organisation enforces its security requirements through the supply chain. Without them, the organisation cannot satisfy ISO 27001 A.5.20, NIST 3.12.1, or DEFSTAN Profile 2 §Supplier Security.
Why contract security obligations matter for management
An organisation's legal and contractual team will negotiate supplier contracts with commercial objectives as the primary focus. Security requirements will often be treated as boilerplate unless the CISO and a director are both present in the negotiation, or unless the security requirements are explicitly defined in an approved schedule that the commercial team knows cannot be removed.
This section defines what must be in every contract with a critical supplier. The standard security schedule (maintained by the CISO at EV-C → Risk Management → Supplier Assessments → Standard Security Schedule) is the document that the commercial team attaches to contracts. Management's role is to ensure that this schedule is not negotiated away, and to be available for escalation when a potential supplier refuses a material security requirement.
Minimum contractual security obligations by access type
TIER 1 — SUPPLIER WITH CUI ACCESS
(any supplier whose staff or systems can access, store, or process our CUI)
Mandatory contractual terms:
1. The supplier must implement and maintain the NIST SP 800-171 security
requirements or equivalent, commensurate with their role in processing CUI.
2. The supplier must notify us of any security incident that has affected
or may have affected our CUI within 24 hours of their discovery of the
incident. This 24-hour clock is not negotiable — it must be met for us
to meet our own DFARS 72-hour reporting obligation.
3. The supplier must permit us to conduct or commission a security
assessment of their controls at our reasonable request, with at least
14 days' notice. Assessments will be no more frequent than annually
unless an incident has occurred.
4. The supplier's personnel who access CUI must have undergone background
checks equivalent to our minimum standard (BPSS for UK personnel;
equivalent for international personnel).
5. The supplier must not sub-contract any element of their service that
involves CUI access without our prior written approval.
6. On termination of the contract, the supplier must return or destroy all
CUI in their possession within 30 days and provide a written confirmation.
Destruction must follow NIST SP 800-88 or equivalent.
7. The supplier must maintain cyber liability insurance at a level agreed
in the contract schedule.
TIER 2 — SUPPLIER WITH OFFICIAL ACCESS (DEFSTAN contracts)
(all Tier 1 obligations above, plus:)
8. The supplier must comply with DEFSTAN 05-138 Profile [0/1/2] as specified
in the contract schedule. The applicable profile is determined by the
CISO in consultation with the contracting authority.
9. The supplier must notify us within 24 hours of any personnel change
affecting named individuals with OFFICIAL access, to allow us to notify
the DEFSTAN contracting authority within our own notification window.
10. The supplier must hold and maintain Cyber Essentials certification for
all systems used to process OFFICIAL information.
TIER 3 — SUPPLIER WITH TRANSIENT OR NO CUI ACCESS
(e.g. cloud services where we control the data; professional services
with no system access; software vendors with no data processing role)
Minimum contractual terms:
1. The supplier must notify us of any security incident that affects their
infrastructure if that infrastructure is used to deliver services to us.
2. The supplier must maintain ISO 27001 certification, SOC 2 Type II, or
equivalent, and must provide us with current certification evidence on request.
3. GDPR: if the supplier processes personal data on our behalf (as a processor),
a GDPR Article 28 Data Processing Agreement must be in place. This is a
legal requirement, not a security preference.
Contract security schedule — what management must ensure
The CISO maintains the standard contract security schedule. The commercial team attaches it to contracts. But three situations require management involvement:
Situation 1 — Supplier refuses a material requirement
If a potential supplier refuses to accept any of the above Tier 1 or Tier 2 requirements, the commercial director must be involved in the decision about whether to proceed. The CISO will assess whether the refusal is negotiable (e.g. the supplier will accept a modified audit right trigger) or is a material gap (e.g. the supplier refuses 24-hour incident notification). If the gap is material and the commercial director wishes to proceed, the CISO will document the gap and the residual risk requires a formal management risk acceptance.
Situation 2 — Legacy contracts without security schedules
The CISO will flag any contract renewal where the current contract does not include a security schedule. The commercial director must ensure that the renewal includes the appropriate tier schedule. If a contract cannot be renegotiated before renewal (e.g. a rolling contract with no break clause), the CISO will document this in the supplier risk register and manage the gap through enhanced assessment frequency.
Situation 3 — Sub-contracting without prior approval
If the CISO becomes aware that a critical supplier has sub-contracted elements of their CUI-handling service without our written approval, the commercial director must be notified within 24 hours. This is both a contractual breach and a potential DFARS compliance issue. The commercial director decides whether to treat it as a breach event or to retroactively approve the sub-contractor under the conditions in our own standard security schedule.
Supply chain compliance obligations — framework context
WHY CONTRACTS MATTER FOR COMPLIANCE CERTIFICATION
ISO 27001 Annex A 5.19 — Information security in supplier relationships:
Requires documented policies and procedures for managing information
security associated with the use of supplier products or services.
Evidence: this page + the supplier register + individual supplier assessments.
ISO 27001 Annex A 5.20 — Addressing security within supplier agreements:
Requires that relevant security requirements are established and agreed
with each supplier based on the type of supplier relationship.
Evidence: signed contracts with security schedules attached.
A certification body auditor who asks to see a supplier contract and
finds no security schedule records a minor or major nonconformity
depending on the access level of the supplier.
NIST SP 800-171 (supporting — no explicit control):
While NIST 800-171 does not have a dedicated supply chain family,
CMMC assessors expect to see that CUI flowing through the supply chain
is controlled. A CUI-handling supplier without appropriate contractual
obligations creates a gap in the CUI boundary.
DEFSTAN 05-138 Profile 2 §Supplier Security:
Explicitly requires that sub-contractors with OFFICIAL data access are
assessed and bound by equivalent security obligations. This is tested
by contracting authority assessors who may ask to see the contract.
Section 3 — Business Impact Analysis executive summary
The BIA is the evidence that the organisation understands which services are most critical, what the maximum tolerable disruption is for each, and what the consequence of failing to recover within that time would be. The full BIA is a technical document owned by the CISO and IT Manager. This section provides the executive summary that management needs to make BCM governance decisions.
What the BIA found
The Business Impact Analysis was completed on [DATE] and reviewed on [REVIEW DATE]. It assessed all services delivered by CUI-scope systems and all services critical to contract delivery. For each service, the BIA identified the Recovery Time Objective (RTO — the maximum time the service can be unavailable) and the Recovery Point Objective (RPO — the maximum data loss that is acceptable if a backup is used to restore).
The BIA also identified the Maximum Tolerable Period of Disruption (MTPD) — the point beyond which disruption causes irreversible consequence. The distinction between RTO and MTPD is important for management: RTO is the target we plan our recovery around; MTPD is the hard deadline beyond which we are in a different kind of crisis.
Critical services — management summary
SERVICE CRITICALITY SUMMARY
Tier 1 — Mission Critical (failure within 4 hours creates irreversible consequence):
Service | RTO | RPO | MTPD | Primary risk if exceeded
─────────────────────────────────────────────────────────────────────────────────
[CUI file server] | 4h | 1h | 8h | DFARS/DEFSTAN reporting;
| | | | contract delivery failure
[Identity / AD] | 2h | 15min | 4h | All staff locked out;
| | | | no system access possible
[Email (receiving)] | 1h | N/A | 8h | Customer and contract
| | | | communications severed
[VPN gateway] | 1h | N/A | 4h | All remote workers locked
| | | | out; contract delivery impact
Tier 2 — Business Critical (failure within 24 hours creates significant impact):
Service | RTO | RPO | MTPD | Primary risk if exceeded
─────────────────────────────────────────────────────────────────────────────────
[ITSM / ticketing] | 24h | 4h | 72h | IT Operations cannot manage
| | | | incidents systematically
[Project management] | 24h | 4h | 48h | Engineering delivery impact
[HR systems] | 48h | 24h | 5 days | Payroll and onboarding delay
Tier 3 — Operational (failure within 48 hours is manageable):
Remaining systems — individual RTOs documented in full BIA
No single Tier 3 failure creates a compliance or contract delivery crisis
Combination of multiple Tier 3 failures may elevate to Tier 2 — CISO assesses
RTO MET BY CURRENT RECOVERY CAPABILITY:
Tier 1 services: [N of N] meet their RTO target
Tier 2 services: [N of N] meet their RTO target
Services where current capability does not meet RTO: [N] — see gaps below
BIA findings — gaps for management awareness
GAP 1: [Service name] — RTO not met
Current recovery capability: [N hours]
Target RTO: [N hours]
Gap: [N hours]
Business consequence of gap: [plain English — what happens if recovery
takes the current [N hours] rather than the target [N hours]]
Treatment options:
Option A: [describe — investment required: £X]
Option B: [describe — investment required: £X]
Option C: Accept the gap — document in risk register as accepted risk
CISO recommendation: [Option — with brief rationale]
Decision required at: [management review / sooner if critical]
GAP 2: [Service name] — RPO not met
[same format]
[Or: "No BIA gaps identified — all critical services meet their RTO and RPO targets."]
What the BIA means for management decisions
The BIA is not a one-time document — it is the foundation for three ongoing management decisions:
Decision 1 — Investment in recovery capability. If a Tier 1 service does not meet its RTO, the organisation is accepting that a failure of that service will exceed its MTPD before recovery is complete. This is a business risk acceptance, not a technical one. The commercial consequence — potential contract default, regulatory reporting obligation — belongs to management, not to IT.
Decision 2 — What to tell customers and contracting authorities if there is an outage. The BIA tells you how long each service can be down. Customers and contracting authorities will ask what happened and when service will be restored. The BIA gives the CISO and IT Manager the technical answer; management must decide the communications approach and whether a contractual notification obligation has been triggered.
Decision 3 — When to invoke the BCP. The Business Continuity Plan is invoked when an outage is expected to exceed the RTO for a Tier 1 service, or when multiple Tier 2 services fail simultaneously. The invocation decision is a management decision — not a technical one. The IT Manager will escalate to management when they assess that the BCP should be invoked; management confirms the invocation and activates the crisis communications protocol.
Section 4 — BCM governance responsibilities
Business continuity is not a technology recovery programme. It is a governance framework that ensures the organisation can continue to deliver its obligations — to customers, to contracting authorities, and to regulators — when its normal operating environment is disrupted. Technology recovery is one component of BCM. This section defines the governance roles.
The BCM governance structure
STRATEGIC LEVEL — Senior Management
Accountability: the organisation's ability to continue operating during
and after a disruptive event; decisions on BCM investment; invocation
of the BCP for significant events; external communications; contractual
and regulatory notifications
TACTICAL LEVEL — CISO and IT Manager
Accountability: technology recovery; technical incident response;
BCM programme maintenance; annual exercise programme; supplier continuity;
escalation to senior management when strategic decisions are needed
OPERATIONAL LEVEL — IT Operations and relevant function heads
Accountability: execution of recovery procedures; technical workarounds;
status reporting to CISO and IT Manager during an incident
GOVERNANCE OVERSIGHT — CISO
Accountability: BCM programme documentation; BIA currency;
annual exercise programme and results; reporting to management review;
integration of BCM with ISO 27001 clauses 5.29 and 5.30
What BCM means for each management role
Managing Director / Chief Executive:
ROLE IN BCM: Crisis leadership and external communications
Invocation trigger:
You will be called when any of the following occur:
A Tier 1 service failure has exceeded or is expected to exceed its RTO
A security incident has affected or may affect our ability to deliver
on a DEFSTAN or DoD contract
A supplier has failed in a way that disrupts our CUI-scope systems
A physical event (fire, flood, loss of premises) affects our ability
to operate
Your decisions:
Whether to notify the DEFSTAN contracting authority (CISO advises;
you confirm — 24-hour clock is running)
Whether to notify DoD via DFARS reporting (CISO advises; you confirm
— 72-hour clock is running)
What to say to affected customers (CISO and IT Manager provide facts;
you decide the communications approach)
Whether to declare a major incident to insurers
Whether to engage legal counsel
Whether to issue a press statement or social media response
What you do NOT need to do:
Manage the technical recovery — that is the IT Manager and CISO
Make decisions about which systems to recover first — that is the BIA
Provide technical updates to regulators — the CISO drafts these
How you will be reached:
CISO will call your mobile directly — not email
If unavailable: CISO will escalate to [named Director deputy]
Call sequence: [CISO number] → [Deputy number] → [Board member number]
Operations Director / Head of Delivery:
ROLE IN BCM: Contract continuity and customer impact management
Invocation trigger:
You will be called when a disruption affects or is expected to affect
our ability to deliver on a specific customer contract or project
Your decisions:
Whether a customer delivery commitment is at risk and whether to
proactively notify the customer (you own the customer relationship;
CISO will advise on what can be disclosed)
Whether to invoke any force majeure or contract relief provisions
Whether to engage sub-contractors or alternative resources to maintain
contract delivery during the disruption
Prioritisation of which contract deliverables are most time-critical
(the IT Manager will use this to prioritise which systems to restore first
within the RTO framework)
What you do NOT need to do:
Manage the technology recovery
Decide which regulatory authorities need to be notified
How you will be reached:
CISO or IT Manager will call your mobile — not email
HR Director / HR Manager:
ROLE IN BCM: Personnel continuity
Invocation trigger:
You will be called when a disruption affects staff access, when a
significant incident involves personnel security concerns, or when
the physical premises are unavailable
Your decisions:
Whether staff can or should work from home during a premises outage
(you will need to coordinate with IT Manager on remote access capacity)
Whether emergency payroll processing is needed if payroll systems are
affected
Whether any personnel welfare support is needed following a significant
incident (e.g. ransomware attack affecting staff data)
Communication to staff about the disruption and expected resolution
What you do NOT need to do:
Make technical decisions about system recovery
Manage regulatory notifications
Finance Director / CFO:
ROLE IN BCM: Financial continuity and insurance
Invocation trigger:
You will be called when a disruption creates a financial exposure,
when insurance claims may be required, or when a regulatory fine
is a possible consequence
Your decisions:
Whether to notify the cyber insurance underwriter (there is typically
a notification obligation within 24–72 hours of a cyber incident —
the CISO will advise on the event; you confirm the notification)
Whether emergency procurement is needed (e.g. replacement hardware,
incident response specialist engagement) — you hold the emergency
budget authority
Whether the board needs to be notified of material financial risk
from the disruption
What you do NOT need to do:
Manage the technical response
Draft the regulatory notifications
BCM invocation flowchart — management decision points
DISRUPTION DETECTED
↓
CISO AND IT MANAGER ASSESS SEVERITY
↓
Is a Tier 1 service affected?
YES ─────────────────────────────────────────────────────────────┐
↓ │
Is recovery expected within RTO? │
YES: IT Manager manages recovery │
CISO monitors and advises │
Management notified by CISO as update, not escalation │
NO ──────────────────────────────────────────────────────────────┘
↓
CISO CALLS [MD/CEO] AND [OPERATIONS DIRECTOR]
Report: what is affected; current recovery estimate;
whether the MTPD will be exceeded; what decisions are needed
↓
MANAGEMENT DECISIONS REQUIRED:
□ Has a DEFSTAN notification obligation been triggered?
YES: CISO drafts notification; [MD/CEO] confirms and authorises
NO: Note decision and continue
□ Has a DFARS notification obligation been triggered?
YES: CISO drafts notification; [MD/CEO] confirms and authorises
NO: Note decision and continue
□ Has an ICO notification obligation been triggered?
YES: CISO drafts notification; [MD/CEO] confirms and authorises
NO: Note decision and continue
□ Do customers need to be notified?
YES: [Operations Director] manages with CISO guidance on content
NO: Note decision and continue
□ Does the insurer need to be notified?
YES: [Finance Director] manages
NO: Note decision and continue
□ Is emergency procurement needed?
YES: [Finance Director] authorises emergency budget
NO: Continue
↓
RECOVERY PHASE
IT Manager leads technical recovery
CISO provides status updates every [2 hours / agreed frequency]
Management available for further decisions as situation evolves
↓
SERVICE RESTORED
CISO confirms RTO outcome to management
Operations Director confirms customer impact resolution
Finance Director notifies insurer of resolution (if notified of event)
↓
POST-INCIDENT REVIEW (within 10 days)
CISO produces EV-D13 post-incident review
Management attends review for incidents affecting Tier 1 services
Actions from review: corrective action register (EV-A03) and
BCM programme updates as appropriate
BCM testing and exercise programme — management obligations
The BCP is only as reliable as the last time it was tested. An untested BCP is a document, not a capability. ISO 27001 clause 5.30 (ICT readiness for business continuity) requires that the organisation verifies, exercises, and maintains the BCM programme.
ANNUAL EXERCISE PROGRAMME (OP-05)
Q1 — BCP Tabletop Exercise (2–3 hours)
Format: CISO presents a disruption scenario; management and IT Manager
walk through how they would respond; gaps and decision bottlenecks are
identified; no actual systems are affected
Management participation required: [MD/CEO] + [Operations Director] + CISO
Why management must attend: the tabletop tests the decision-making chain,
not just the technical response. A tabletop without senior management
attending only tests the IT team — not the governance model that determines
whether regulatory notifications are made, whether customers are called,
or whether emergency budget is released.
Q2 — IT Failover Technical Test (IT Manager and IT Operations — no management
participation required unless a material gap is discovered)
Format: IT Manager and IT Operations fail over specific Tier 1 services
to the backup environment; RTO is measured; results reported to CISO
Management notification: CISO reports results at next quarterly risk posture
update. If any Tier 1 service does not meet its RTO in the test: CISO
escalates to management within 48 hours of test completion.
Q3 — Full DR Exercise (IT team — management awareness required)
Format: simulated full site failure; IT team tests end-to-end recovery
of all Tier 1 services from backup; RTO measured for each service
Management notification: results reported to CISO; escalation if any
Tier 1 service RTO is not achieved
Q4 — Combined BCM and Cyber Incident Tabletop (management participation required)
Format: scenario combining a cyber incident (ransomware or equivalent)
with a partial service outage; tests the interface between the incident
response process and the BCM process; tests the decision chain including
regulatory notification decisions
Management participation required: [MD/CEO] + [Operations Director] +
[Finance Director] + CISO + IT Manager
Why this is a mandatory management event: this is the scenario most
likely to occur in practice; it is also the scenario that most clearly
requires management decisions that cannot be delegated. An organisation
that has never rehearsed this scenario will make worse decisions when
it happens in reality.
EXERCISE REPORTS:
Each exercise produces an exercise report (EV-D15)
Findings from exercises feed the corrective action register (EV-A03)
Exercise results are presented at the annual management review as an
input under ISO 27001 clause 9.3.2(c) (ISMS performance)
BCM coverage of compliance obligations
WHAT BCM MUST ENSURE WE CAN DO DURING AN OUTAGE:
DFARS §252.204-7012:
If a cyber incident occurs during a system outage, the 72-hour reporting
obligation still runs. The CISO must be able to access the DIBNet portal
and submit the report even if primary systems are unavailable.
BCM requirement: CISO has an out-of-band access mechanism for DIBNet
(personal mobile device with MFA) that does not depend on internal
infrastructure. Tested: [date of last verification]
DEFSTAN notification (24-hour clock):
Same requirement — the CISO must be able to send the notification to the
contracting authority even during an outage. The contracting authority's
email address and the CISO's personal email are documented in the IRT
contact list (EV-D14) and accessible via the CISO's personal mobile.
Tested: [date of last verification]
ICO breach notification:
The ICO notification portal is accessible from any internet-connected
device. The CISO has the account credentials in the PAM vault with
an offline backup maintained at [secure location].
Tested: [date of last verification]
ISO 27001 audit evidence access:
If an ISO 27001 surveillance audit is scheduled and our internal systems
are unavailable, we need to provide the certification body with access to
evidence. The CISO maintains an offline evidence package (key EV items
exported to PDF) updated quarterly.
Location: [cloud storage location accessible without internal VPN]
Last updated: [date]
Section 5 — Decisions management must own
A consolidated reference of every supplier security and BCM decision that requires management authority rather than CISO authority. This section is the single-page reference that management can consult before any meeting, incident, or contract decision.
Supplier security decisions
DECISION AUTHORITY REFERENCE — SUPPLIER SECURITY
Routine supplier management (CISO authority — no management decision needed):
• Conducting and scheduling supplier security assessments
• Issuing and reviewing security questionnaires
• Moving supplier to Amber (management notified; no decision required)
• Negotiating minor contract security schedule updates
• Renewing a contract where security obligations are unchanged
Management decision required:
SCENARIO TRIGGER AUTHORITY TIMELINE
─────────────────────────────────────────────────────────────────────────────────
Move supplier to Red Material unmitigated Director Within 30 days
and decide: accept / restrict / gap or supplier + CISO of Red rating
terminate the relationship incident confirmed
Formal risk acceptance for a Supplier assessed Director At risk acceptance
supplier with unmitigated gaps Red; management (named or management review
where relationship continues decides to accept individual)
Approve CUI access for a new New contract or Commercial Before access
supplier relationship Director + CISO is granted
Authorise regulatory notification Supplier incident Director Within 2 hours
following supplier incident confirms CUI (any available of CUI exposure
affecting our CUI exposure Director) confirmed
Approve emergency restriction of Immediate threat CISO (initiates) Same day;
a supplier's CUI access from supplier → Director retroactive
compromise (confirms) approval 24h
Approve sub-contractor security Supplier proposes Commercial Before
schedule for a critical supplier a sub-contractor Director + CISO sub-contractor
sub-contracting CUI work for CUI work accesses CUI
Approve security terms in a new New contract Commercial Before contract
contract with a CUI-handling negotiation Director + CISO execution
supplier requiring deviation from (for any
standard security schedule deviation)
BCM decisions
DECISION AUTHORITY REFERENCE — BUSINESS CONTINUITY
Routine BCM management (CISO / IT Manager — no management decision needed):
• Routine system recovery within RTO
• IT failover tests (Q2 exercise)
• BCP and BIA updates that do not change RTO/RPO/MTPD targets
• Scheduling and running BCM exercises
Management decision required:
SCENARIO TRIGGER AUTHORITY TIMELINE
─────────────────────────────────────────────────────────────────────────────────
Invoke the Business Continuity Outage expected MD/CEO or Immediately
Plan to exceed Tier 1 delegated on CISO
RTO Director escalation
Authorise DFARS regulatory Cyber incident Director Within 2 hours
notification detected or (any available) of discovery
suspected on (72-hour clock
CUI systems is running)
Authorise DEFSTAN contracting Incident affecting Director Within 1 hour
authority notification OFFICIAL systems of discovery
(24-hour clock
is running)
Authorise ICO breach notification Personal data Director + DPO Within 4 hours
breach detected or (if appointed) of discovery
suspected (72-hour clock)
Approve customer notification Operations Director Operations Within 2 hours
of service disruption assessment that Director + MD of CISO
contract may be (depending on confirmation
affected customer) outage exceeds RTO
Authorise emergency procurement Recovery requires Finance Same day
(e.g. replacement hardware, resources beyond Director
IR specialist engagement) normal budget
Notify insurer of a cyber Cyber incident Finance Per insurance
incident or BCM event Director policy terms
triggering coverage (typically 24–72h)
Approve investment to close BIA gap identified Director At management
a BIA gap (RTO not met by in BIA or in + Finance review or sooner
current capability) exercise Director if gap is critical
Approve revised RTO/RPO/MTPD BIA review reveals Director At annual BIA
targets for any critical service targets need update + CISO review
Decide whether to close the Exercise results Director Within 5 days
Q4 combined exercise as reveal a material + CISO of exercise report
satisfactory or require a gap in management being issued
repeat before C3PAO assessment decision-making
The decisions management must never leave to the CISO alone
Some decisions are structured so that the CISO is the natural point of escalation. But there are five decisions where management delegating to the CISO — even informally — creates a compliance, contractual, or legal problem:
1 — CMMC senior official affirmation The CMMC affirmation must be signed by a senior company official. The CISO can prepare the document and advise on its accuracy. The CISO cannot sign it. If the CISO signs it, the affirmation does not satisfy 32 CFR 170.4 and is not valid for SPRS submission.
2 — Regulatory notification authorisation DFARS, ICO, and DEFSTAN notifications are formal regulatory communications made on behalf of the organisation. The CISO drafts them and advises on timing. A Director must authorise them. If the CISO submits a DFARS report without Director awareness, this is not a process failure — but if a regulatory authority later investigates and asks who authorised the notification, the answer must be a named Director, not "the CISO decided."
3 — Risk acceptance above Moderate The risk appetite statement specifies that High-risk acceptances require CISO sign-off and management notification. Very High-risk acceptances require board-level sign-off. If the CISO accepts a High or Very High risk without management involvement, the risk register will show an accepted risk that does not have the required authority behind it — this is an ISO 27001 finding and potentially a CMMC compliance gap.
4 — Supplier access to CUI following a supplier incident If a supplier has experienced a security incident and their systems may have been compromised, the decision about whether to continue allowing them access to our CUI is a management decision. The CISO will advise. Management decides. If management is unreachable and the CISO restricts access in an emergency, that is defensible. If management is available and defers to the CISO, the decision record will show that management was not engaged — which is a governance gap.
5 — BCP invocation The Business Continuity Plan is invoked by a management decision, not by the IT Manager. The IT Manager executes recovery procedures — but the invocation of the BCP, with its implications for customer communication, contractual notifications, and emergency resource deployment, is a strategic decision that belongs at Director level.
Section 6 — Supplier and BCM evidence log
The CISO maintains this log as a record of management engagement with supplier security and BCM governance. It is reviewed at ISO 27001 surveillance audits and provides evidence that management accountability is being exercised in these domains.
FORMAT PER ENTRY:
[DATE] — [Event type] — [Description] — [Authority / Participants]
EVENT TYPES:
SUPPLIER-ASSESSMENT Assessment completed; rating assigned or changed
SUPPLIER-RED Supplier moved to Red; management notified
SUPPLIER-DECISION Management decision on supplier relationship
SUPPLIER-CONTRACT Contract security schedule agreed or updated
SUPPLIER-INCIDENT Supplier security incident notification received
BCM-EXERCISE BCM exercise completed; results presented
BCM-INVOCATION BCP invoked for a real disruption event
BCM-GAP-DECISION Management decision on BIA gap or RTO investment
BIA-REVIEW BIA reviewed and confirmed or updated
NOTIFICATION-AUTH Regulatory notification authorised by Director
| Date | Event type | Description | Authority / Participants |
|---|---|---|---|
| [Date] | SUPPLIER-ASSESSMENT | [Supplier] assessed — Green (no change) | CISO |
| [Date] | SUPPLIER-INCIDENT | [Supplier] ransomware incident — CUI not affected | CISO + [Director name] notified |
| [Date] | BCM-EXERCISE | Q4 combined cyber + BCM tabletop exercise | [MD] + [Ops Director] + [Finance Director] + CISO + IT Manager |
| [Date] | BIA-REVIEW | Annual BIA review confirmed — no changes to RTO/RPO | CISO + IT Manager + [Ops Director] endorsement |
Version and review
| Version | Date | Prepared by | Approved by | Key changes |
|---|---|---|---|---|
| 1.0 | [DATE] | CISO | [Director name] | Initial publication |
Page owner: CISO (supplier security) + [Operations Director] (BCM) · Review cycle: Annual at management review; quarterly CISO commentary updated · SCM: isms-management · Questions: [ciso@organisation.com]