Supplier Incident Reporting
Confluence page header
Page title: Supplier Incident Reporting
Parent: ISMS Home → 09 · Supplier Security Policy
SCM variant: isms-all-staff (read — for internal staff managing supplier
relationships and for suppliers reading their obligations)
isms-management (read)
isms-security (full access — CISO maintains)
isms-it-staff (read)
Page owner: CISO
Last reviewed: [DATE]
Next review: Annual — reviewed alongside the Incident Management Policy
and after any significant supplier incident
Related pages: Supplier Security Obligations (standard-tier obligations)
Critical Supplier Security Obligations (critical-tier)
04 · Incident Management Policy (internal IRP)
AT-IR · Incident Response (technical detail for IT staff)
Data Handling and Classification Rules for Suppliers
The most important thing on this page
If you are reading this during or after a security incident, call the CISO now. Do not read this page from the beginning. Do not send an email. Call:
CISO — 24 hours a day, 7 days a week for security incidents:
Name: [CISO name]
Mobile: [CISO mobile number]
If the CISO cannot be reached:
IT Manager: [IT Manager name] [IT Manager mobile number]
The reason telephone contact is required: Our regulatory obligations under DFARS and DEFSTAN have clocks that start running from the moment an incident is discovered — not from when the investigation is complete, not from when you are confident about what happened, and not from when you send an email. A phone call takes two minutes and starts the clock accurately. An email sent at 2:00am that is not read until 9:00am costs us seven hours on a clock we cannot afford to lose.
Who this page applies to
This page applies to every supplier, contractor, and third-party service provider who has any of the following in relation to our organisation:
- Access to our IT systems, networks, or cloud environments
- Access to data we classify as INTERNAL, OFFICIAL, OFFICIAL-SENSITIVE, or CUI
- Physical access to our Zone 2 or Zone 3 areas
- A sub-contract role that involves handling our data on our behalf
- A relationship that forms part of our CMMC, DEFSTAN, or ISO 27001 compliance boundary
The incident reporting obligations on this page are not aspirational — they are contractual and, in many cases, legally required. Section 6 explains the consequences of non-reporting in plain terms. The short version is that a supplier who fails to report an incident affecting our data does not just create a problem for us — it creates a legal and contractual problem for itself.
Section 1 — What counts as a reportable security incident
The most common mistake suppliers make is waiting to report until they are certain what happened. The reporting obligation arises when you discover an event — not when you have investigated it. The question is not "did this definitely affect their data?" It is "could this have affected their data?"
If the answer to that question is "possibly yes," the reporting obligation is engaged. Notify us, tell us what you know, and investigate simultaneously.
1.1 — Events that are always reportable
The following events must be reported regardless of your assessment of whether our data was affected. These are events where the nature of the event alone, without any specific evidence of data access, is sufficient to engage the reporting obligation.
Ransomware or destructive malware on any system used in our engagement
Ransomware encrypts or destroys data. It often involves a period of prior reconnaissance where the attacker has read access to systems before deploying the encryption. If ransomware has affected any system that holds, processes, or connects to our data, you cannot know in the early stages whether our data was exfiltrated before the encryption. Report it immediately and preserve the forensic evidence.
Compromise of credentials used to access our systems
This includes: passwords discovered in a data breach (even from a different service, if you use the same password for our systems — which you must not, but if it has happened, report it); phishing attacks that may have captured credentials; credential stuffing attacks against accounts that have access to our systems; physical loss of a device where credentials are stored; and any other event where credentials that could provide access to our systems may have been obtained by an unauthorised party.
Unauthorised access to any system holding our data
This includes: unauthorised remote access; unauthorised physical access to servers or workstations; discovery of an attacker in your network who may have had access to systems that hold our data; and any access event where the accessing party was not authorised to access that system.
Loss or theft of any device or media holding or used to access our data
This includes: a laptop used to access our systems being left on a train; a USB drive containing our files being stolen; a phone used for MFA for our systems being lost; printed documents containing our classified information being misplaced; and any physical loss of anything that contains, could contain, or provides access to our data.
A breach or suspected breach of your own systems by a third party
If you discover that a third party has accessed your systems without authorisation, and those systems are part of your supply chain for our engagement, the event is reportable to us. Even if the specific systems affected do not appear to hold our data, you may not be certain of that without investigation — and we need to know so we can assess the risk from our side simultaneously.
Supply chain compromise affecting software or services you use in our engagement
If you use third-party software or cloud services to deliver your engagement with us, and those services are confirmed as compromised (through a vendor advisory, a national warning, or your own discovery), report it to us. SolarWinds, Log4Shell, and similar events illustrate why supply chain compromise in software used by our suppliers can directly affect our posture.
1.2 — Events that are reportable unless you can immediately rule out impact
The following events are reportable unless you can immediately and definitively confirm that our data was not involved. "Definitively" means based on objective technical evidence, not an assumption.
Security incidents on systems adjacent to those used in our engagement
If an incident has affected a system in the same network segment as systems you use for our engagement, the lateral movement risk makes it reportable until you can confirm isolation.
Phishing attacks that resulted in any user clicking a link or opening an attachment
Phishing is the most common initial access vector. If any user at your organisation who has access to our systems or data clicked on a phishing link or opened a malicious attachment, report it. Phishing campaigns are often reconnaissance for larger attacks — even if the immediate result appears to be a false alarm, the compromise may be continuing.
Large or unusual data transfers from systems holding our data
If your monitoring identifies unusual outbound data volumes from systems holding our data, report it. Exfiltration often precedes ransom deployment or other visible damage by days or weeks.
A member of your staff with access to our systems being investigated for or suspected of criminal activity
This includes: staff being investigated by police for financial fraud, espionage, or other serious crime; staff who have been identified as having inappropriately accessed data; and staff whose behaviour suggests a potential insider threat. The CISO will assess whether access restrictions are appropriate while the investigation proceeds.
Discovery that your background screening for an individual with our access was incorrect or incomplete
If you discover that a BPSS check or SC clearance for a named individual with access to our OFFICIAL or CUI data was incomplete, incorrectly recorded, or fraudulently obtained, report it immediately.
Discovery of a vulnerability in your systems or software that provides a pathway to our data
A Critical or High severity vulnerability in a system you use to deliver our engagement is reportable within 5 business days. If the vulnerability is in systems that directly hold or process our CUI or OFFICIAL data, report within 24 hours.
1.3 — Events that are not reportable but should be disclosed at the annual assurance review
The following are not immediately reportable but must be disclosed in your annual assurance questionnaire and assurance review:
- Security incidents fully investigated and confirmed with no impact on our data, where the incident nevertheless represents a degradation of your security posture
- Loss of security certifications (ISO 27001, Cyber Essentials Plus) — reportable within 10 business days but not a security incident per se
- Changes to your security team or CISO role — not a security incident; notify us within 30 days
- Regulatory enforcement actions or investigations related to information security or data protection — disclose in the annual assurance questionnaire
Section 2 — The notification timelines you are bound by
The notification timelines in this section are not arbitrary. They are calibrated to the regulatory obligations that bind us as a result of our contracts. If you do not notify us within the stated window, we may breach our own regulatory obligations as a direct result. Regulatory clocks cannot be paused, transferred, or negotiated once they have started.
2.1 — The timeline structure
NOTIFICATION TIMELINE REFERENCE
Your tier: Standard Critical
────────── ──────────────────────────────────────────
Category A — Immediate life-or-death-of-engagement incidents:
2 hours 1 hour (24/7, including weekends and holidays)
Category B — Serious incidents with possible impact on our data:
4 hours 2 hours (24/7)
Category C — Significant but lower-immediate-risk incidents:
24 hours 4 hours
(business (24/7)
hours)
Category D — Disclosure items (not time-critical):
5 business 5 business
days days
─────────────────────────────────────────────────────────────────────
WHY YOUR TIER MATTERS FOR THESE TIMELINES:
Critical-tier suppliers have privileged access to our production systems
or access to CUI / OFFICIAL data. An incident at a Critical-tier supplier
can directly enable a second-stage attack against us, or may have already
exposed the data that triggers our regulatory clock. The tighter timelines
for Critical-tier reflect this elevated exposure.
If you are unsure of your tier, check your engagement documentation or
contact the CISO. When in doubt, treat yourself as Critical-tier.
2.2 — Category A incidents — call immediately
Category A triggers (call within 1 hour for Critical-tier;
call within 2 hours for Standard-tier):
• Ransomware or destructive malware confirmed on any system used in
our engagement or that holds our data
• Confirmed exfiltration or confirmed access by an unauthorised party
to data we have provided to you (any classification)
• Loss or theft of a device or media that holds CUI or OFFICIAL data
we have provided, or that holds credentials to our systems
• Compromise of credentials used to access our systems (confirmed or
suspected — do not wait to confirm)
• A third party has been confirmed as accessing your systems and
those systems hold or connect to our data
• A member of your staff with access to our CUI or OFFICIAL data
has been arrested or is under active criminal investigation
WHAT STARTS THE CLOCK:
The clock starts at the moment any person at your organisation
becomes aware that the event may have occurred.
Not when your investigation is complete.
Not when your CISO is notified internally.
Not when you have confirmed the scope.
Not when you return to the office.
The moment of awareness is the start of the clock. If a junior
engineer discovers malware on a server at 23:00 on a Saturday,
the clock started at 23:00 on Saturday. Your CISO needs to know
by 23:00 on Sunday at the absolute latest (24-hour absolute limit),
and our CISO needs to know by 01:00 on Sunday (2-hour window for
Critical-tier suppliers).
2.3 — Category B incidents — notify within 2–4 hours
Category B triggers:
• A security incident on your systems where our data MAY have been
affected but you cannot yet confirm — investigation ongoing
• A confirmed phishing attack where a user with access to our systems
clicked a link or opened an attachment
• Anomalous data transfer or activity detected on systems holding
our data where the cause is not yet determined
• A confirmed breach at a sub-contractor or cloud provider you use
in our engagement, where our data may have been stored
Note: "may have been affected but cannot confirm" is the critical phrase
here. The reporting obligation does not require certainty. It requires
that you believe there is a real possibility of impact. If your
investigation is taking more than 2 hours for Critical-tier or 4 hours
for Standard-tier, notify us now and continue investigating.
2.4 — Category C incidents — notify within 4–24 hours
Category C triggers:
• Security incidents confirmed as not affecting our data, but that
represent a degradation of your security controls relevant to our
engagement (e.g. your SIEM has been offline for 48 hours; your
EDR platform was uninstalled from a workstation used for our engagement)
• Discovery of a Critical severity vulnerability in systems that
hold or process our CUI or OFFICIAL data
• Loss of device or media that was used to access our systems but
does not appear to hold our data (MFA device, access card)
• Any regulatory enforcement action or investigation specifically
related to the data processing you perform for us
• Departure of a named individual with CUI or OFFICIAL access
where the offboarding was not completed (see DEFSTAN obligations,
Section 5.2)
Note: Category C for Critical-tier suppliers is 4 hours — within business
hours. For Standard-tier, Category C is 24 hours within business hours.
For either tier, if the event occurs on a Friday evening, the clock does
not pause until Monday — 24 hours is 24 hours.
2.5 — Category D disclosure items — within 5 business days
Category D items (for both tiers):
• Loss of ISO 27001, Cyber Essentials Plus, or SOC 2 certification
• Addition of a sub-contractor to your engagement with us who will
have access to our data (this requires our approval — see Critical
Supplier Security Obligations Section 6.1)
• Discovery that your security questionnaire submission contained
an inaccuracy (voluntarily disclosed before we discover it)
• Changes to the individuals who have access to our systems
(additions or removals not already captured by regular offboarding)
• A significant change to your security architecture or posture
that affects the assurances you provided in your last annual
assurance submission
Section 3 — How to report
3.1 — The reporting sequence
THE CORRECT SEQUENCE:
Step 1: Pick up the phone. Call the CISO.
Do this first. Before internal escalation.
Before writing a formal incident report.
Before notifying your own management, if that will take time.
The call does not need to be a polished briefing. It needs to be made.
"We think we may have had a ransomware incident on a server that
holds some of your data. I don't have the full picture yet but
wanted to call you immediately." — this is a perfect notification.
Step 2: Confirm in writing within 2 hours of the call.
After the phone call, send an email to [ciso@organisation.com]
with the subject line specified in Section 3.3.
The email is your written record that the notification was made.
It is also the start of the formal incident record on our side.
Step 3: Provide structured detail within 24 hours.
Within 24 hours of your initial notification, provide the detailed
incident report using the template in Section 3.4.
If your investigation is still in progress, provide what you know
and indicate what is still being determined.
Step 4: Provide daily updates until the incident is resolved.
Send a brief status update to the CISO daily while the incident
is active. The update does not need to be long — a paragraph
covering what has been confirmed, what is still being investigated,
and what containment actions have been taken.
Step 5: Provide a post-incident report within 30 days.
A full post-incident review report — see Section 3.5.
3.2 — Contact details for reporting
PRIMARY CONTACT — call first, always:
CISO: [CISO name]
Mobile: [CISO mobile number] — available 24/7 for Category A and B incidents
Office: [CISO direct line] — business hours only
Email: [ciso@organisation.com] — for written confirmation and documents
(not for first notification)
SECONDARY CONTACT — if CISO cannot be reached within 15 minutes:
IT Manager: [IT Manager name]
Mobile: [IT Manager mobile number]
Email: [itmanager@organisation.com]
TERTIARY ESCALATION — if both CISO and IT Manager cannot be reached:
[Senior Director name]
Mobile: [Director mobile number]
FOR WRITTEN NOTIFICATIONS AND DOCUMENTS:
Email: [ciso@organisation.com]
Subject line format: see Section 3.3
DO NOT:
× Send your initial notification only by email — call first
× Send to a general inbox or support address — it must reach the CISO
× Notify your own account manager or sales contact — they cannot
start our internal incident response process
× Wait until your working hours start — Category A and B incidents
require notification at any hour
3.3 — Email subject line format
Every written communication related to a supplier security incident must use the following subject line format. This ensures the email is correctly routed and the incident record is opened promptly.
SUPPLIER SECURITY INCIDENT NOTIFICATION
Subject line format:
SUPPLIER INCIDENT — [YOUR COMPANY NAME] — [CATEGORY A/B/C/D] — [DATE]
Examples:
SUPPLIER INCIDENT — ACME MANAGED SERVICES LTD — CATEGORY A — 2024-09-14
SUPPLIER INCIDENT — NORTHFIELD CLOUD CORP — CATEGORY B — 2024-11-02
SUPPLIER INCIDENT — ATLAS CONSULTING — CATEGORY D — 2025-01-18
For daily update emails:
SUPPLIER INCIDENT UPDATE — [YOUR COMPANY NAME] — [DATE] — UPDATE [N]
Example: SUPPLIER INCIDENT UPDATE — ACME MANAGED SERVICES LTD — 2024-09-15 — UPDATE 1
For post-incident report:
SUPPLIER INCIDENT REPORT — [YOUR COMPANY NAME] — [INCIDENT REF] — FINAL
Example: SUPPLIER INCIDENT REPORT — ACME MANAGED SERVICES LTD — SR-2024-042 — FINAL
The incident reference number (SR-YYYY-NNN) will be provided by the CISO after the initial notification. Use it in all subsequent communications.
3.4 — Initial written notification — what information to provide
Send this within 2 hours of the telephone notification. Incomplete information is acceptable — provide what you know and clearly mark what is still being determined. Do not delay the email waiting for more information.
SUPPLIER INCIDENT INITIAL NOTIFICATION — TEMPLATE
TO: [ciso@organisation.com]
SUBJECT: SUPPLIER INCIDENT — [YOUR COMPANY NAME] — [CATEGORY] — [DATE]
SECTION 1 — INCIDENT OVERVIEW
Your company name: _______________________________________________
Incident date and time (when discovered): _______________________
Discovery method (how the incident was found): __________________
☐ Automated alert (SIEM / EDR / AV)
☐ User report
☐ External notification (customer / vendor / NCSC / law enforcement)
☐ Routine review discovered anomaly
☐ Attacker communication (ransomware note)
☐ Other: ______________________________________________________
Incident category (your assessment):
☐ Category A — immediate impact / confirmed compromise
☐ Category B — possible impact / under investigation
☐ Category C — no confirmed impact / control degradation
☐ Category D — disclosure item
SECTION 2 — WHAT HAPPENED (provide what you know; mark unknown items)
Brief description of the incident (plain English — 3–5 sentences):
___________________________________________________________________
___________________________________________________________________
___________________________________________________________________
Systems affected or potentially affected:
☐ [System name / description] — ☐ Confirmed affected ☐ Possibly affected
☐ [System name / description] — ☐ Confirmed affected ☐ Possibly affected
☐ Under investigation — full system inventory not yet completed
SECTION 3 — OUR DATA
Does this incident affect systems that hold, process, or provide
access to our data?
☐ Yes — confirmed
☐ Possibly — still under investigation
☐ No — explain how this has been confirmed: ____________________
If Yes or Possibly — which of our data categories may be involved?
☐ Internal information
☐ Official information (DEFSTAN contracts)
☐ CUI — Controlled Unclassified Information (DoD contracts)
☐ Personal data (our employees / customers / others)
☐ Other: ______________________________________________________
Has any of our data been confirmed as accessed or exfiltrated?
☐ Yes — describe: ____________________________________________
☐ No — confirmed because: ____________________________________
☐ Unknown — investigation ongoing
SECTION 4 — WHAT YOU HAVE DONE SO FAR
Containment actions taken (tick all that apply):
☐ Affected systems isolated from the network
☐ Affected accounts disabled / credentials revoked
☐ VPN or remote access suspended
☐ Forensic preservation started (images of affected systems)
☐ Incident response team engaged (internal or external)
☐ Law enforcement notified: ☐ Yes — force: _________ ☐ Not yet
☐ Your cyber liability insurer notified: ☐ Yes ☐ Not yet
☐ Other: ______________________________________________________
SECTION 5 — CURRENT STATUS
Current state of the incident (one sentence):
___________________________________________________________________
What is your incident lead currently doing?
___________________________________________________________________
When do you expect to have more information to share?
Next update time: _____________________________________________
SECTION 6 — YOUR CONTACT DETAILS
Incident lead (the person at your organisation managing this):
Name: ___________________________________________________________
Role: ___________________________________________________________
Mobile: _________________________________________________________
Email: __________________________________________________________
Will this person be available 24/7 for the next 48 hours?
☐ Yes ☐ No — available: ______________________________________
Secondary contact:
Name: ___________________________________________________________
Mobile: _________________________________________________________
3.5 — Structured post-incident report — within 30 days
Provide this report within 30 days of the incident being resolved. If the incident is not resolved within 30 days, provide a progress report at 30 days and continue updating weekly.
SUPPLIER POST-INCIDENT REPORT — TEMPLATE
Incident reference: SR-[YYYY]-[NNN] (assigned by CISO at initial notification)
Your company: ___________________________________________________
Date of initial notification: ___________________________________
Date incident resolved: ________________________________________
Report date: ___________________________________________________
Report prepared by (name and role): ____________________________
SECTION 1 — INCIDENT SUMMARY
Full description of what happened:
___________________________________________________________________
___________________________________________________________________
Complete timeline (key events with timestamps — UTC):
[YYYY-MM-DD HH:MM UTC] — [Event description]
[continue for all key events from discovery to resolution]
SECTION 2 — WHAT AFFECTED OUR DATA AND SYSTEMS
Our data confirmed affected: ☐ Yes ☐ No
If Yes:
Data category affected: _______________________________________
Approximate volume / scope: ___________________________________
Nature of access (read / modified / exfiltrated / deleted): ___
Period during which access occurred: __________________________
Individuals whose personal data was affected (if applicable):
Category: ☐ Our employees ☐ Our customers ☐ Other: ________
Approximate number of individuals: __________________________
Our systems directly affected: ☐ Yes ☐ No
If Yes — which systems: ______________________________________
SECTION 3 — ROOT CAUSE ANALYSIS
What was the root cause of the incident? (Be specific — not "phishing
attack" but "a phishing email impersonating [vendor] was sent to
[name/role]; the email bypassed email gateway filtering because
[specific reason]; the recipient clicked the link and entered credentials
because [specific reason]; the attacker used those credentials to access
[specific system] because [MFA was not enforced on that system].")
Primary root cause:
___________________________________________________________________
___________________________________________________________________
Contributing factors:
___________________________________________________________________
___________________________________________________________________
SECTION 4 — WHAT YOU HAVE DONE IN RESPONSE
Containment actions (complete list with dates):
___________________________________________________________________
Eradication actions (how the threat was removed):
___________________________________________________________________
Recovery actions (how systems were restored):
___________________________________________________________________
SECTION 5 — WHAT IS CHANGING AS A RESULT
Changes to your controls or security programme as a result of this
incident (be specific — not "we will improve our monitoring" but
"we have implemented [specific tool/rule/policy] that will detect
[specific condition] within [specific timeframe]"):
Control changes implemented:
___________________________________________________________________
Control changes planned (with target dates):
___________________________________________________________________
Does this incident reveal any inaccuracy in your last annual assurance
submission to us?
☐ Yes — describe the inaccuracy and the corrected position: ____
☐ No
SECTION 6 — REGULATORY NOTIFICATIONS MADE
ICO notification:
☐ Made — reference: _________________ Date: _________________
☐ Not required — reason: _____________________________________
☐ Pending — expected date: ___________________________________
Other regulatory notifications:
☐ NCSC: reference: _________________ Date: __________________
☐ Law enforcement: force: ____________ Date: _________________
☐ Other: ____________________________________________________
SECTION 7 — LESSONS LEARNED
What would have prevented this incident?
___________________________________________________________________
What would have detected it sooner?
___________________________________________________________________
What would have contained it faster?
___________________________________________________________________
Was this incident reportable to us under the notification obligations
in the Supplier Incident Reporting page?
☐ Yes — was it reported within the required timeline?
☐ Yes ☐ No — explain: _____________________________________
☐ No — it fell below the reporting threshold
Prepared by: ______________________________ Date: _______________
Section 4 — Evidence preservation — what you must not destroy
Evidence preservation is a requirement, not a request. Under DFARS §252.204-7012(f), when a cyber incident occurs involving covered defence information (CUI), the contractor must preserve images of compromised systems and other relevant forensic evidence for 90 days. This obligation extends to suppliers in our supply chain.
4.1 — What you must preserve immediately
When you discover an incident that may have affected our CUI or OFFICIAL data, before you take any remediation action:
EVIDENCE TO PRESERVE — DO THIS BEFORE ANY REMEDIATION
System images:
Create forensic images (bit-for-bit copies) of any affected system's
storage before making any changes to those systems.
If you do not have forensic imaging capability in-house, do not
attempt to remediate affected systems until you have either:
(a) engaged a forensic specialist to image the systems first, or
(b) confirmed with our CISO that image preservation has been waived
for specific systems for operational continuity reasons.
"We needed to restore service" is not a valid reason to destroy
forensic evidence. If systems must be restored urgently, image them
first, then restore. Imaging a server takes 30–90 minutes. A call to
us to confirm the approach takes 5 minutes.
Log files:
Export and preserve all log files from affected systems:
Windows event logs (Security, System, Application)
Authentication logs (Entra ID / AD sign-in logs)
Email server logs (send, receive, access logs)
Web server access logs
VPN connection logs
EDR / AV detection and activity logs
SIEM alert logs
Network flow logs if available
Preserve for a minimum of 90 days from the date of incident discovery.
Do not allow automated log rotation or deletion to remove these logs
during the 90-day preservation period.
Network capture:
If you have the capability: a network packet capture of traffic
to and from affected systems from the point of discovery forward
is valuable forensic evidence. If your EDR or network monitoring
tool has retrospective capture capability, retrieve that capture now.
Memory:
If affected systems are still running (not yet powered off or rebooted),
a memory dump can capture evidence of running malicious processes that
will be lost on reboot. If you have this capability and a forensic
specialist who can take a memory dump safely, do so before any reboot.
4.2 — What you must not do before preservation is complete
DO NOT — before forensic preservation is confirmed complete:
× Reimage, reformat, or restore affected systems from backup
(this destroys the forensic evidence of what happened)
× Delete or rotate log files on affected systems
× Power off or restart servers without first taking a memory image
(some malware lives only in memory and is lost on restart;
running process information is valuable evidence)
× Run automated remediation tools that automatically delete
detected malware files before they have been examined
(malware samples are forensic evidence of the attack vector)
× Patch or update affected systems before image capture
(patching changes system state and may obscure how compromise occurred)
× Communicate the breach externally before discussing with our CISO
(we need to coordinate our external communications, including
regulatory notifications, together)
EXCEPTIONS:
If an affected system is actively causing damage to other systems
(for example, a system is actively encrypting a file share or
is actively exfiltrating data), isolate it immediately — pull
the network cable or use your EDR isolation function. Then preserve.
Active threat isolation (stopping ongoing damage) takes precedence
over forensic preservation. Stopping the harm comes first.
But isolation is not the same as destruction — isolate the system,
do not rebuild it.
4.3 — Preservation period
Preserve forensic evidence for a minimum of 90 days from the date of incident discovery. If we or our DoD customer requests that forensic evidence be provided, make it available within the timeframe we specify. If you need to decommission an affected system before the 90 days has elapsed, contact the CISO for confirmation that the evidence preservation obligation has been satisfied before decommissioning.
Section 5 — Consequences of non-reporting
5.1 — The legal and regulatory context
Non-reporting of a security incident is not simply a contractual breach — it can have regulatory and legal consequences for both you and us. This section describes those consequences plainly. It is not intended as a threat; it is context that explains why the reporting obligations exist and why they are enforced.
5.2 — DEFSTAN consequences of non-reporting
DEFSTAN 05-138 Profile 1 §Incident Management requires that security incidents affecting OFFICIAL information are reported to the contracting authority within 24 hours of discovery. Our obligation to the contracting authority runs from the moment an incident is discovered — by us or by anyone in our supply chain working on the contract.
If you suffer an incident affecting our OFFICIAL data and do not notify us, we cannot notify the contracting authority within 24 hours. Our DEFSTAN obligation is then breached. A breach of this specific obligation can trigger:
Contract consequences: - The contracting authority may issue a formal finding against us for failure to meet the incident notification requirement - A persistent pattern of late reporting may affect our ability to bid for, renew, or perform on further MOD contracts - The contracting authority may require an inspection of our security posture and supply chain practices as a condition of continued contract performance
Your direct contractual exposure: Your contract with us requires you to notify us of security incidents within the specified timeframes. Non-reporting is a breach of your contract. We reserve the right to terminate the engagement for material breach if a reportable incident is discovered that was not reported by you within the required timeframe.
The DEFSTAN notification clock cannot be restarted. Once the 24-hour window has passed, it has passed. There is no mechanism for retroactive compliance. The only mitigation available to us if you report late is to demonstrate to the contracting authority that the delay was caused by our supplier and that we have taken action to prevent recurrence. Late reporting by a supplier does not protect you — it becomes evidence in a finding against both parties.
5.3 — CMMC and DFARS consequences of non-reporting
DFARS §252.204-7012 clause (c) requires that we report cyber incidents to DoD through the DIBNet portal within 72 hours of discovery. "Discovery" means when we or anyone in our supply chain working on covered contracts becomes aware of the incident.
If you suffer a cyber incident involving our CUI and fail to notify us within the required timeframe, the 72-hour DFARS clock continues to run from the moment your organisation became aware — regardless of when you told us. We cannot backdate our notification to DoD.
Criminal liability: The False Claims Act creates personal criminal liability for knowingly submitting false or misleading information to the US government. Our CMMC senior official has affirmed annually that our cybersecurity posture is accurately represented in our SPRS submission. If that submission relied on representations from you about your security posture that turn out to be false, this is a matter that our legal counsel will need to assess. Suppliers who knowingly misrepresent their security posture or who conceal reportable incidents from us are creating risk to themselves under both US and UK law.
SPRS implications: A breach by us resulting from a supplier's failure to report may require us to update our SPRS score — which may affect our competitive position in DoD procurement.
Malicious software reporting: DFARS §252.204-7012(f)(2) specifically requires contractors to report malicious software discovered on systems processing CUI, and to provide the malicious software to DoD for analysis if requested. If you discover malware on systems processing our CUI and delay reporting, you may be preventing us from meeting this obligation.
Contract termination: A supplier who fails to report a cyber incident involving our CUI within the required timeframe, and where this failure causes us to breach our DFARS reporting obligation, has committed a material breach of their contract with us. We reserve the right to terminate immediately and to seek damages for the regulatory consequences we suffer as a result.
5.4 — UK GDPR consequences of non-reporting
Under UK GDPR Article 28(3)(f), your Data Processing Agreement (DPA) with us requires you to notify us of personal data breaches without undue delay. We have defined "without undue delay" as within 24 hours of discovery. This is the standard DPA provision for all our supplier relationships involving personal data.
If you fail to notify us within 24 hours of discovering a personal data breach and this causes us to miss the 72-hour ICO reporting window, the ICO may consider our failure to report in time as an aggravating factor in any enforcement action. The ICO does not recognise "our processor failed to tell us in time" as a complete defence for a controller who misses the reporting deadline.
ICO enforcement: The ICO can fine data controllers up to £17.5 million or 4% of global annual turnover for serious breaches of UK GDPR. Late reporting of a personal data breach is itself a breach of the accountability principle, separate from the underlying breach. A supplier's failure to report that causes our late notification to the ICO is a contributing cause of any enforcement action we face.
Your direct liability under the DPA: Your DPA with us makes you directly liable for compliance with Article 28 obligations. Failure to notify us of a personal data breach within 24 hours is a breach of the DPA. We are entitled to seek indemnification from you for regulatory penalties we incur as a result of your late notification.
5.5 — The asymmetry of reporting versus non-reporting
THE COST OF REPORTING (even if it turns out to be unnecessary):
• A 5-minute phone call
• A 30-minute written notification
• Some reputational discomfort for having had an incident
• A potentially precautionary restriction of access while
investigation continues
Total: a few hours of effort; temporary disruption; no legal exposure
THE COST OF NOT REPORTING (when you should have):
• Breach of contract — grounds for immediate termination
• Regulatory liability under DFARS (potential criminal prosecution
in the US for False Claims Act violations)
• ICO enforcement risk (UK GDPR)
• DEFSTAN contracting authority finding against us (which we pursue
against you)
• Civil liability for losses we suffer as a direct result of your
late notification
• Reputational damage to your organisation in a sector where trust
is the primary procurement criterion
Total: potentially catastrophic commercial, legal, and regulatory
consequences for your organisation
The asymmetry is why our notification timelines are tight and why we enforce them. We are not trying to create administrative burdens for suppliers. We are trying to ensure that when something goes wrong, we can act together quickly enough to limit the damage to both of us.
Section 6 — Special circumstances
6.1 — What to do if you receive a law enforcement or government request
If a law enforcement body, government agency (including the US DoD IG, US FBI, UK police, the ICO, or any other authority), or any other third party contacts you and asks you to provide information about, access to, or evidence relating to the data you process for us:
Step 1 — Do not comply immediately. Most legal instruments (warrants, court orders, subpoenas) have a compliance timeline that is more than a few hours. Unless you are facing an immediate search by officers physically present at your premises (in which case comply with the search but immediately call us), you typically have time to notify us before producing anything.
Step 2 — Call the CISO immediately. Tell us the nature of the request, which authority has made it, and the compliance deadline. We will seek legal advice and advise you on how to respond.
Step 3 — Do not notify us if legally prohibited from doing so. Some instruments (such as certain national security letters in the US) include a gag clause that prohibits you from telling anyone you have received the instrument. If this applies, you cannot notify us — but notify us to the maximum extent the law permits. If you are legally prohibited from notification, we understand and accept that. What we cannot accept is a choice not to notify us when you are legally able to do so.
Why this matters: A law enforcement request for our data may be related to an investigation that we are also subject to. We need to know so that we can exercise any legal rights (such as privilege or confidentiality claims) before the data is produced, and so that we can prepare for the regulatory and reputational implications.
6.2 — What to do if you receive a ransom demand
If you receive a ransom demand from an attacker who claims to have accessed your systems:
Call the CISO first. Before paying. Before negotiating. Before doing anything other than documenting the demand. We need to know immediately.
Do not pay the ransom without notifying us. Payment of a ransom may be prohibited by UK or US sanctions law if the attacker is a designated entity. Paying a sanctioned entity is itself a crime, regardless of the circumstances. We need to assess this alongside you. Paying without our knowledge and discovery after the fact creates additional complications.
Preserve evidence. The ransom note itself is evidence. Any communication channel the attacker has used (darknet site, email, chat) should be documented and preserved. The attacker's claims about what data they have accessed are relevant to our assessment of whether our data is at risk.
We will not make the ransom payment decision for you. That is a decision for your organisation's board and legal counsel. What we need from you is: notification immediately; access to the information about what data the attacker claims to hold; and your involvement in our incident response so we can act jointly.
6.3 — What to do if you discover an incident that occurred in the past
If you discover that an incident occurred some time ago — for example, your forensics team has determined that an attacker had access to your systems for six weeks before detection — and you are trying to determine whether our data was affected:
Report based on what you know now, not on what you wish you had known. The clock started when the discovery was made. The fact that the incident happened six weeks ago does not mean you have six weeks' worth of retroactive reporting time — the clock is 24 hours from your discovery, not from the incident itself.
Tell us what you know about the timeline. If forensic evidence indicates the attacker had access from a specific date, that is the date range relevant to our assessment of exposure. Tell us the suspected compromise window, even if it is wide ("we believe the attacker had access between [Date 1] and [Date 2]").
Do not understate the timeline. We understand the instinct to present the most favourable interpretation of the forensic evidence. If the evidence is ambiguous about whether the attacker accessed specific systems, present the ambiguity — do not present it as a definitive "no impact" when it is actually "uncertain." We will assess the ambiguity alongside you.
Section 7 — Our obligations to you after you notify us
The incident reporting relationship is not one-directional. When you notify us of an incident, we commit to:
WHAT WE WILL DO AFTER YOU NOTIFY US:
Within 15 minutes of receiving your call:
Confirm receipt and provide you with an incident reference number
Advise you of any immediate actions we are taking on our side
(for example, suspending your access to our systems as a precaution —
we will tell you if we are doing this; we will not do it silently)
Within 1 hour:
Confirm whether we believe a DFARS, DEFSTAN, or ICO notification
obligation has been triggered based on the information you have provided
Advise you of any evidence preservation actions we need you to take
Within 24 hours:
Confirm our own regulatory reporting position
If we have made regulatory notifications, tell you what we have reported
(subject to any legal advice that limits what we can share)
Provide you with a named incident coordinator on our side for the
duration of the active incident
Throughout the incident:
Keep you informed of any actions we are taking that affect your
systems, access, or data
Tell you what information we have shared with regulators that
pertains to your organisation
Work with you rather than against you — you are our partner in
managing this, not our adversary
After the incident:
Share our own post-incident review findings with you where relevant
to your systems or controls
Discuss lessons learned that we are implementing on our side
Confirm when any access restrictions we imposed have been lifted
and why they were imposed
WHAT WE WILL NOT DO:
We will not disclose the details of your incident to other customers,
suppliers, or third parties without your consent — except where we
are legally required to do so in regulatory notifications.
We will not use a disclosed incident as an automatic basis for
contract termination — a supplier who discloses promptly and manages
an incident well is demonstrating the security culture we expect.
A supplier who discloses late, manages the incident poorly, or
fails to report at all creates a different conversation.
Section 8 — Quick reference cards
Print-ready summary cards for supplier staff. Laminate and keep next to workstations or in the site security pack.
Card 1 — Is it reportable?
┌─────────────────────────────────────────────────────────────────┐
│ IS THIS INCIDENT REPORTABLE TO [ORGANISATION]? │
└─────────────────────────────────────────────────────────────────┘
Ask yourself these questions:
1. Does it involve any system that holds, accesses, or connects to
their data or systems?
YES → Reportable. Continue to Question 2.
NO → Probably not reportable (check with your CISO to confirm).
2. Could their data have been affected, even if you haven't confirmed it?
YES → Report now. Do not wait for confirmation.
NO → Is this a firm technical finding, or an assumption?
If an assumption: report. If a firm technical finding:
still disclose at your next annual assurance review.
3. Are you unsure about any of the above?
UNSURE → Call their CISO now. It takes 2 minutes. The cost of
an unnecessary call is zero. The cost of missing a
mandatory notification is severe.
CALL: [CISO name] — [CISO mobile number]
EMAIL: [ciso@organisation.com]
SUBJECT: SUPPLIER INCIDENT — [YOUR COMPANY] — [CATEGORY A/B/C/D] — [DATE]
Card 2 — The clock
┌─────────────────────────────────────────────────────────────────┐
│ WHEN DOES THE CLOCK START? │
└─────────────────────────────────────────────────────────────────┘
THE CLOCK STARTS: When any person at your organisation becomes
aware that an incident MAY have occurred.
NOT: when the investigation is complete.
NOT: when your CISO is informed internally.
NOT: when business hours start.
NOT: when you decide to report.
YOUR NOTIFICATION TIMELINE:
If you are a CRITICAL-TIER supplier:
Category A (ransomware / confirmed breach): CALL WITHIN 1 HOUR
Category B (possible impact): CALL WITHIN 2 HOURS
Category C (no confirmed impact): NOTIFY WITHIN 4 HOURS
If you are a STANDARD-TIER supplier:
Category A (ransomware / confirmed breach): CALL WITHIN 2 HOURS
Category B (possible impact): CALL WITHIN 4 HOURS
Category C (no confirmed impact): NOTIFY WITHIN 24 HOURS
AFTER THE CALL:
Written notification within 2 hours of the call
Full structured report within 24 hours
Daily updates until resolved
Post-incident report within 30 days of resolution
Card 3 — Do not destroy evidence
┌─────────────────────────────────────────────────────────────────┐
│ DO NOT DESTROY EVIDENCE │
└─────────────────────────────────────────────────────────────────┘
BEFORE you reimage, restore, patch, or delete anything on affected
systems — CALL [CISO name] on [CISO mobile].
We may have a regulatory obligation to preserve forensic evidence
of the incident for 90 days. Evidence destruction before preservation
is complete may be a DFARS violation.
YOU MUST PRESERVE:
☐ Disk images of affected systems (bit-for-bit copies)
☐ All log files (Windows events, auth logs, VPN, EDR, network)
☐ Network captures if available
☐ Memory dumps if systems still running and capability exists
☐ Malware samples (do not delete detected malware before capture)
☐ Ransom notes, attacker communications
YOU CAN (AND SHOULD) DO IMMEDIATELY:
☐ Isolate affected systems from the network
☐ Revoke compromised credentials
☐ Stop ongoing harm
CALL FIRST: [CISO name] [CISO mobile number]
Contacts and further information
INCIDENT REPORTING — ALL CONTACTS
CISO (primary — call first, 24/7 for Category A and B):
[CISO name]
[CISO mobile number]
[ciso@organisation.com]
IT Manager (secondary — 24/7 for Category A):
[IT Manager name]
[IT Manager mobile number]
[itmanager@organisation.com]
Senior escalation (if both above unavailable):
[Director name]
[Director mobile number]
For written notifications and documents:
[ciso@organisation.com]
Subject: SUPPLIER INCIDENT — [YOUR COMPANY] — [CATEGORY] — [DATE]
For general enquiries about what to report:
[ciso@organisation.com]
Response within 3 business hours for general enquiries
(do not use this address for incident notifications — call first)
Related pages:
Supplier Security Obligations — standard-tier obligations
Critical Supplier Security Obligations — critical-tier obligations
Data Handling and Classification Rules for Suppliers
Supplier Onboarding — how your engagement was set up
Confluence page version and review
Evidence filing:
Supplier incident notifications received:
EV-D → Incident Response → Incidents → [YYYY] → Supplier-[SR-YYYY-NNN]
Supplier post-incident reports:
EV-D → Incident Response → Incidents → [YYYY] → Supplier-[SR-YYYY-NNN]
→ Post-Incident Report
Supplier notification log (summary of all notifications received):
EV-C → Risk Management → Supplier Assessments → Incident Notification Log
Retention:
Supplier incident records: 3 years minimum from incident resolution
DFARS-related incident records: 5 years (DFARS record retention requirement)
Records where litigation is reasonably anticipated: indefinitely pending
resolution
Review triggers (in addition to annual review):
Any supplier incident where the notification timeline was not met
Any change to DFARS reporting requirements
Any change to DEFSTAN incident notification requirements
Any ICO guidance change affecting our processor obligations
Any significant supplier incident that reveals a gap in this guidance
Review cycle: Annual — reviewed alongside the Incident Management Policy
Page owner: CISO
Questions: [ciso@organisation.com]
| Version | Date | Prepared by | Key changes |
|---|---|---|---|
| 1.0 | [DATE] | CISO | Initial publication |