Supplier Exit and Offboarding
Confluence page header
Page title: Supplier Exit and Offboarding
Parent: ISMS Home → 09 · Supplier Security Policy
SCM variant: isms-all-staff (read — for commercial, procurement, and IT staff
who manage supplier exits)
isms-management (read)
isms-security (full access — CISO maintains)
isms-it-staff (read — IT Operations executes the technical steps)
Page owner: CISO (security obligations) + IT Manager (technical steps)
+ Commercial Director (commercial and contractual coordination)
Last reviewed: [DATE]
Next review: Annual
Related pages: Supplier Security Obligations (standard-tier)
Critical Supplier Security Obligations (critical-tier)
Supplier Onboarding (the mirror of this page)
Data Handling and Classification Rules for Suppliers
FC-03 · User Access Control (internal JML technical detail)
EV-C → Risk Management → Supplier Assessments (evidence)
Why this page exists
Every supplier engagement ends. The end of an engagement is not an administrative formality — it is a security event. At the point a supplier relationship terminates, we face a set of risks that do not exist while the engagement is active: data that the supplier legitimately held during the engagement must be returned or destroyed; access that was granted must be revoked in a controlled and verifiable way; equipment that carries our data must be recovered; and the supplier's ongoing obligations — particularly around confidentiality — must be confirmed, not assumed.
The failure mode is predictable. Without a structured exit process, what typically happens is: the commercial relationship ends, the contract expires, and then at some point later we discover that the supplier's accounts are still active, their copies of our data have never been confirmed deleted, and no one tracked whether the access card was returned. This is not a theoretical risk — it is the standard outcome of an unmanaged exit. Every security assessment that covers supplier management will ask whether we can demonstrate that former suppliers no longer have access and that their data holdings have been resolved.
This page structures the exit process so that outcome does not occur.
Section 1 — What triggers the offboarding process
The offboarding process is triggered by any of the following events:
OFFBOARDING TRIGGER INITIATED BY TIMELINE
────────────────────────────────────────────────────────────────────────────────
Planned contract end Commercial team Minimum 30 days
(contract reaches its natural or CISO before end date
expiry date)
Early termination Commercial team Immediately on
(contract terminated before or CISO termination
expiry, by either party) or Legal
Supplier relationship suspended CISO Immediately on
(access suspended pending (management suspension decision
investigation or as a result decision)
of a Red risk rating)
Named individual departure Supplier CISO Same day as
(a specific individual at the notifies our departure is
supplier leaves or changes role) CISO confirmed
Contract scope reduction Commercial team Before the
(supplier's access is being or CISO narrowing takes
narrowed — some access effect
remains but some is removed)
Acquisition or merger of CISO Within 30 days
supplier by another company (informed by of acquisition
(new ownership creates a new commercial or announcement
risk profile) supplier)
Mutual agreement to Commercial team As agreed; minimum
transition to a different or CISO 5 business days
supplier
1.1 — Planned exits: starting early
For planned contract end dates, the offboarding process should begin at least 30 calendar days before the end date. This is not a bureaucratic preference — it is the time needed to:
- Complete the data inventory so the supplier knows what they hold and how to return or destroy it
- Allow the supplier to complete their internal data deletion processes (which may involve backup rotation cycles that take days or weeks to complete)
- Arrange equipment collection or courier delivery
- Conduct the post-access SIEM review after accounts are deactivated
- Allow for disputes or complications that the final week should not be handling
A commercial team that notifies the CISO of a contract end date 3 days before it expires has created a situation where access cannot be safely managed and data deletion cannot be verified within the required timeline. The commercial team must notify the CISO at least 30 days before any planned contract end date.
1.2 — Emergency exits: same-day action
Where termination is immediate — following a security incident, a material contract breach, or a supplier risk rating change to Red — the offboarding process begins the same day. In these circumstances:
- Access is suspended or revoked immediately by IT Operations on CISO instruction
- The data return and deletion process begins within 24 hours of the access suspension
- The full exit checklist is completed within 5 business days of the suspension
- The commercial and legal teams are notified simultaneously — the exit checklist does not wait for commercial resolution
The distinction between access suspension and account deletion matters in emergency exits. In an emergency, accounts are suspended (access blocked; accounts retained for audit trail). Accounts are deleted after the 90-day forensic retention hold, in line with our standard JML procedure.
Section 2 — Data return and deletion requirements
2.1 — The scope of the data return and deletion obligation
At the end of an engagement, the supplier must resolve all copies of our data that they hold. "Resolve" means one of two things: return the data to us, or destroy it securely. The contract specifies which option is required; where the contract is silent, secure deletion is the default.
What counts as "our data" for exit purposes:
SCOPE OF DATA REQUIRING RESOLUTION AT EXIT
Explicitly in scope — must be resolved:
• All files, documents, and databases provided to the supplier by us
• All work product created by the supplier in connection with our engagement
(reports, designs, code, specifications, analysis)
• All copies, excerpts, summaries, and derivatives of the above
• Personal data about our employees, customers, or others processed
on our behalf under the DPA
• CUI and OFFICIAL information provided to or created by the supplier
in connection with our engagement
• Any data stored on the supplier's systems, in cloud services they use,
in their email systems, and in their backup infrastructure
Implicitly in scope — the supplier must confirm whether held:
• Email correspondence containing our classified information
(each email is a data copy — email retention policies may hold
our data long after it was originally exchanged)
• Instant messenger conversations containing our data (Teams channels
shared with us, Slack workspaces, WhatsApp business groups)
• Downloaded or cached web content from our systems
(browser caches, downloaded files from portals or intranets)
• Screenshots, recordings, or notes containing our data
• Any copies made "for convenience" during the engagement
Out of scope — does not need to be deleted:
• Commercially public information about us (our website, published
documents, public contracts register entries)
• The supplier's own correspondence about our engagement that does
not contain our classified information (scheduling emails, invoices,
meeting invitations with no data content)
• Anonymised or genuinely aggregated data where re-identification
is not possible
2.2 — Data inventory: what the supplier must provide before data is resolved
Before any data can be returned or deleted, both parties need to know what data is being resolved. The supplier is responsible for producing a data inventory — a list of what they hold.
Data inventory format:
SUPPLIER DATA INVENTORY — EXIT REQUIREMENT
Submitted by: [Supplier name]
Engagement reference: [Onboarding ref SR-YYYY-NNN]
Inventory date: [DATE]
Prepared by: [Name and role — CISO or equivalent]
SECTION A — DIGITAL DATA
For each system or location holding our data:
Location | Data type / description | Volume | Holds CUI? | Holds personal data? | Holds OFFICIAL?
───────────────────────────────────────────────────────────────────────────────────────────────────────────────────
[Supplier file share] | [Project documents — 3 years] | [45GB] | ☐ Yes ☐ No | ☐ Yes ☐ No | ☐ Yes ☐ No
[Cloud storage svc] | [Work product deliverables] | [12GB] | ☐ Yes ☐ No | ☐ Yes ☐ No | ☐ Yes ☐ No
[Email system] | [Correspondence + attachments]| [Unknown] | ☐ Yes ☐ No | ☐ Yes ☐ No | ☐ Yes ☐ No
[Backup system] | [System backups — 90 day ret] | [Unknown] | ☐ Yes ☐ No | ☐ Yes ☐ No | ☐ Yes ☐ No
[Sub-contractor A] | [Specify what they hold] | [specify] | ☐ Yes ☐ No | ☐ Yes ☐ No | ☐ Yes ☐ No
SECTION B — PHYSICAL DATA
Item type | Description | Quantity | Holds CUI? | Holds personal data? | Location
───────────────────────────────────────────────────────────────────────────────────────────────────────────────────
[Printed documents] | [Project reports — physical] | [15 docs] | ☐ Yes ☐ No | ☐ Yes ☐ No | [Office filing room]
[USB drive] | [Project data backup USB] | [2 units] | ☐ Yes ☐ No | ☐ Yes ☐ No | [Engineer's desk]
[Other physical media]| [describe] | [specify] | ☐ Yes ☐ No | ☐ Yes ☐ No | [specify]
SECTION C — SUB-CONTRACTOR DATA
For each sub-contractor who holds our data:
Sub-contractor name: _______________________________________________
Data held: ________________________________________________________
Resolution plan: __________________________________________________
Your DPA obligation to them covers deletion: ☐ Yes ☐ No — explain
SECTION D — DECLARED COMPLETENESS
I confirm that this inventory represents all copies of [Organisation name]'s
data that [Supplier company] holds, to the best of my knowledge and belief.
I confirm that I have instructed all relevant personnel to contribute to
this inventory.
Signed: ___________________________ Date: ___________________________
Name and role: _________________________________________ (CISO or equivalent)
The data inventory must be submitted to the CISO within 10 business days of the exit being triggered. For planned exits (30 days' notice), the inventory should be submitted within the first 10 days to allow 20 days for the actual data resolution and verification.
2.3 — Data return procedure
When return is required (contract specifies return, or CISO requests it):
Return must be via a secure, encrypted transfer method. The same methods required for transmitting our classified data during the engagement apply at exit:
APPROVED RETURN METHODS BY DATA CLASSIFICATION
Internal data:
Acceptable: SFTP, encrypted archive via email (AES-256, strong passphrase
sent separately), our secure file transfer portal
Not acceptable: plain email attachments, consumer file sharing services
Official and CUI data:
Acceptable: our approved secure file transfer portal, end-to-end encrypted
email (S/MIME or PGP), SFTP with certificate authentication
Not acceptable: any unencrypted method, consumer services, plain email
Physical: if returning on physical media — encrypted device
(FIPS-validated hardware encryption), hand-carried by named custodian
with chain of custody record, or tracked courier with full tracking
confirmation to us
Personal data:
As per your DPA obligations — encrypted in transit via SFTP or approved
encrypted transfer service; UK/EEA data residency for the transfer
endpoint; confirmation receipt required
After return: The supplier must confirm in writing that all returned data has been deleted from their systems following transfer. Return is not complete until the deletion confirmation is provided. Returning a copy and retaining another is not a return — it is a partial resolution that is treated as non-compliance.
2.4 — Secure deletion procedure
When deletion is required (the default, or where contract specifies destruction):
The deletion method required depends on the media type and the classification of the data. For data held in cloud services and on-disk file systems, the following minimum standards apply:
DELETION REQUIREMENTS BY MEDIA AND CLASSIFICATION
Cloud storage (S3, Azure Blob, Google Cloud Storage, etc.):
• Delete all objects and empty all buckets holding our data
• Where customer-managed keys (CMK) are used: delete the encryption
key after confirming all data is deleted — key deletion renders any
remaining cached data cryptographically inaccessible
• Confirm with the cloud provider that deletion is immediate and that
no soft-delete or recovery period applies (some services have a
30-day soft-delete period — confirm this is purged, not just deleted)
• For multi-region storage: deletion must apply to all regions
where our data is stored, not just the primary region
File servers and NAS:
• Secure deletion using overwrite tools (NIST SP 800-88 Clear method
minimum for data destined for reuse within your organisation)
• For Internal-classified data: standard secure deletion (overwrite)
• For Official or CUI data: NIST SP 800-88 Purge or equivalent
(multi-pass overwrite or ATA Secure Erase for SSDs)
• Document the deletion: tool used, date, files/volumes covered
Backup systems:
• Immediate deletion of backup jobs containing our data from the
backup schedule (prevents new backups being created after exit)
• Purge of backup sets containing our data from the backup repository
• Where backup purge requires waiting for the backup rotation cycle:
confirm the schedule and provide a date by which all backups will
be purged (maximum 90 days from exit date)
• Backup purge confirmation provided in writing within 5 days of
the purge completion
Email systems:
• Delete all emails and attachments containing our classified data
from all mailboxes (including Sent Items, Deleted Items, Archives)
• If email archiving is in use: purge the archive records for the
period of our engagement
• Exchange / M365: use Compliance Centre eDiscovery or Content Search
to locate and purge relevant email content
• If complete purge is impractical due to your retention policies:
notify the CISO — we will assess whether your retention policy
creates a residual risk that requires a compensating control
Physical media (USB drives, laptops, printed documents):
Follow the methods specified in Section 3 (Equipment and Physical
Media Return and Destruction)
Personal data:
As above, plus: confirm deletion satisfies your DPA Article 28
obligation — deletion must be verifiable, not just acknowledged
2.5 — Certificate of deletion — mandatory for CUI, OFFICIAL, and personal data
For CUI, OFFICIAL, and personal data, a certificate of deletion must be provided to the CISO within 30 days of the data deletion being completed. The certificate must contain:
CERTIFICATE OF DELETION — REQUIRED CONTENT
From: [Supplier company name]
To: [Our organisation name] — CISO
Date: [Certificate date]
Engagement ref: [SR-YYYY-NNN]
I, [Name, Role — CISO or equivalent], on behalf of [Supplier company],
hereby certify that:
1. All copies of [Organisation name]'s data — including CUI, OFFICIAL
information, and personal data processed under our Data Processing
Agreement — have been securely deleted from our systems and the
systems of our sub-contractors listed in Annex A.
2. The deletion was completed on [DATE] and encompassed the following:
[List each system, service, and data type confirmed deleted, with
the deletion method used for each]
3. Our backup systems have been purged of all [Organisation name] data.
Backup purge was completed on [DATE] / is expected to be completed
by [DATE — maximum 90 days from deletion date].
4. Physical media containing [Organisation name]'s data has been
destroyed as described in the attached destruction certificate
[reference EV-D25 equivalent from the supplier] / returned to
[Organisation name] on [DATE] per the return confirmation [reference].
5. Email correspondence containing [Organisation name]'s classified data
has been [deleted from all mailboxes and archives on [DATE] /
retained under our standard email retention policy — contents are
subject to continuing confidentiality obligations].
6. Sub-contractor data holdings have been resolved:
[For each sub-contractor: company name, data resolved by [method],
date confirmed, evidence held by [you / sub-contractor]]
Signed: _______________________ Date: _______________________________
Name: _________________________ Role: _______________________________
Company: ____________________________________
For personal data, this certificate also serves as the confirmation required under UK GDPR Article 28(3)(g) — confirmation of deletion at the end of the processing relationship.
2.6 — Timeline summary for data resolution
DATA RESOLUTION TIMELINE
Planned exit Emergency exit
(≥30 days notice) (immediate)
─────────────────────────────────────────────
Data inventory Day 1–10 Day 1–5 (within 5 business days)
submitted to CISO
Data return or Day 10–25 Day 5–20 (within 15 business days)
deletion completed of access suspension
Certificate of Day 25–30 Within 5 business days of deletion
deletion received
Backup purge Within 90 days Within 90 days of exit date
confirmed of exit date
Personal data: DPA Within 30 days Within 30 days of exit date
deletion confirmed of exit date
Section 3 — Equipment and physical media return
3.1 — Inventory of equipment and media at exit
Before any equipment or physical media can be returned or disposed of, both parties need a complete inventory. This is produced jointly — we provide our asset register entries for equipment issued to the supplier; the supplier provides their own list of physical media used in the engagement.
Our responsibility: The CISO will provide the supplier with a list of: - Any equipment or devices we have issued to the supplier (if applicable) - Any physical media we have given to the supplier containing our data
Supplier's responsibility: The supplier must provide us with a list of: - Any physical media (USB drives, external hard drives, printed documents, optical discs) they have created or used that contains our data - Any devices they have used to access our systems that may hold cached or locally stored copies of our data
3.2 — Return of equipment we have issued
If we have issued any equipment to the supplier for the purposes of the engagement — devices, access tokens, FIDO2 keys, access cards, or any other physical item — these must be returned before the engagement closes.
ISSUED EQUIPMENT RETURN PROCEDURE
1. CISO provides the supplier with the list of issued items from our
asset register (EV-D22)
2. Supplier confirms receipt of the list and identifies any items
that are lost, damaged, or cannot be returned
3. Return method:
For items under £200 in value: post or courier with tracking
and insurance; supplier provides the tracking reference to CISO
For access tokens, FIDO2 keys, and access cards: courier with
tracking, or hand delivery at the final site visit. Do not post
access credentials without tracking.
For items over £200 in value, or for any item containing data
(laptops, tablets, external drives): hand delivery by named
individual with our IT Operations engineer present to confirm
receipt and verify condition. No unaccompanied courier for
high-value or data-bearing equipment.
4. IT Operations verifies each returned item against the asset register:
• Correct item (serial number matches EV-D22 entry)
• In acceptable condition
• Data state confirmed (for data-bearing equipment:
IT Operations verifies whether data is present; if so,
the device enters our standard sanitisation process
before being reissued or disposed of)
5. EV-D22 updated: item status changed from "Issued to [supplier]"
to "Returned [date]" or "Lost/damaged — to be managed under
contract terms"
6. Items confirmed returned: CISO provides written receipt to supplier
within 5 business days of return
3.3 — Supplier equipment containing our data
Where the supplier has used their own equipment (laptops, external drives, USB drives) to work with our data, that equipment must be sanitised before it is reused for any other purpose, or physically destroyed.
The supplier's obligation:
For equipment containing CUI or OFFICIAL data: the supplier must sanitise the equipment using NIST SP 800-88 Purge-equivalent methods before reusing it. If the equipment is being disposed of rather than reused, it must be physically destroyed using an ADISA-certified vendor, with individual asset serial numbers on the destruction certificate.
The supplier must provide us with evidence of sanitisation or destruction: - For sanitisation: an internal sanitisation log entry showing the tool used, method, date, and engineer — equivalent to our EV-D26 format - For destruction: a destruction certificate from the disposal vendor, listing individual asset serial numbers — equivalent to our EV-D25 format
Why we require this evidence: Our CUI and OFFICIAL data handling obligations do not end at the boundary of our own systems. A supplier who destroys our data on their servers but retains a laptop with a local cache of that data has not discharged the data resolution obligation. The destruction certificate is our evidence that the data has been resolved at the media level.
3.4 — Printed documents containing our data
Printed documents are often overlooked in exit processes. Any printed document containing our classified data that was created or received during the engagement must be destroyed using a cross-cut shredder rated at DIN 66399 Level P-4 minimum for INTERNAL and OFFICIAL material, and P-5 or above for OFFICIAL-SENSITIVE and CUI.
For large volumes of printed material, the supplier may use a confidential waste service — the waste company must provide a collection certificate, and the supplier must provide a copy of that certificate to the CISO.
A simple written declaration that all printed material has been destroyed (with the destruction method, date, and signatory) is acceptable for small volumes.
Section 4 — Access revocation procedure
4.1 — The access revocation sequence
Access revocation is the most time-sensitive element of the exit process. Unlike data deletion, which requires the supplier's cooperation and takes time, access revocation is entirely within our control and must happen on the day it is triggered.
The procedure for access revocation at supplier exit mirrors our internal JML leaver procedure with the following adaptations for supplier accounts. IT Operations executes this procedure on instruction from the CISO. IT Operations does not accept instructions to revoke supplier access from the commercial team, the supplier themselves, or any person other than the CISO or the IT Manager.
SUPPLIER ACCESS REVOCATION — STEP-BY-STEP PROCEDURE
Trigger received by CISO: [planned exit notification / emergency exit event]
Onboarding reference: SR-[YYYY]-[NNN]
Target revocation date: [DATE] (planned exits); Immediate (emergency exits)
STEP 1 — Entra ID account deactivation
Action: Disable all Entra ID accounts associated with the supplier engagement
Who: IT Operations
Timeline: Planned exit — on the final day of the engagement; Emergency exit —
within 1 hour of CISO instruction
Technical action:
For each named individual's account:
Entra admin centre → Users → [account] → Edit properties → Account status:
Set to "Blocked from sign in" (disable, not delete)
Reason: disabled accounts are retained for 90 days to preserve audit trail;
deletion removes the sign-in history which may be needed for post-exit review
Service accounts (if any were created for the supplier):
Disable all supplier-associated service accounts in Entra ID and AD
Remove service account from any application API permissions
Rotate any secrets or certificates associated with the service account
Evidence: Screenshot of disabled account status in Entra ID admin console
Filed at: EV-D04 leaver record → supplier exit entry
STEP 2 — Active session revocation
Action: Revoke all active authentication tokens immediately
Who: IT Operations
Timeline: Immediately after Step 1, without delay
Technical action (PowerShell):
For each account: Revoke-MgUserSignInSession -UserId [UPN]
Verify: Sign-in logs in Entra ID show no successful authentications
from the supplier accounts after the revocation timestamp
For cloud services with separate authentication:
AWS: deactivate IAM user access keys; delete the access keys
Azure subscription: remove role assignments from the supplier's account
Third-party SaaS: log in to each service and remove the supplier's account
(Maintain a list of all external services the supplier accessed —
this was captured at onboarding in EV-D03; review that list now)
STEP 3 — MFA method removal
Action: Remove all registered MFA methods from the disabled accounts
Who: IT Operations
Timeline: Within 2 hours of Step 1
This prevents any possibility of MFA bypass re-enabling access if the
account were accidentally re-enabled. It also prevents the authentication
method (phone number, hardware token) being repurposed.
Technical action: Entra admin centre → Users → [account] →
Authentication methods → Remove all methods
STEP 4 — VPN access removal
Action: Remove from VPN-Suppliers or equivalent VPN group
Who: IT Operations
Timeline: Within 2 hours of Step 1
Verify: Attempt a VPN connection with the revoked credentials
(from a controlled test environment) — confirm connection fails
STEP 5 — ACS card deactivation (on-site access suppliers)
Action: Deactivate all physical access cards
Who: Facilities Manager, instructed by CISO
Timeline: Same day as Step 1 (planned exit — on the final day;
emergency exit — same hour)
Technical action (ACS console):
Each card: Status → Inactive (not deleted — retain card record)
Zone 3 access list: remove the individual from the EV-D23 list
Card return:
Planned exit: confirm card has been returned at the final site visit
If card not returned before the final day: deactivate regardless;
mark card in ACS as "Lost/Not returned"; do not issue a replacement
to anyone else until the matter is resolved
Emergency exit: deactivate immediately; arrange collection of the
card separately
STEP 6 — Application-specific access removal
Review the access granted at onboarding (EV-D03) and remove each item:
☐ Document management system access: remove user from project workspaces
☐ ITSM system access: remove user from all queues and projects
☐ Code repository access: remove from all repositories
☐ Monitoring / SIEM access (if any was granted): remove user
☐ Cloud console access: remove all role assignments
☐ Network device management access (if any): remove user
☐ Any other bespoke access granted for this engagement: [specify]
For each item: record the removal date and the person who performed it
STEP 7 — Certificate revocation (if device or client certificates were issued)
Action: Revoke all certificates issued to the supplier's devices or users
Who: IT Operations
Timeline: Within 24 hours of Step 1
Certificate types to check:
VPN client certificates
Device identity certificates (if supplier devices were enrolled in
our internal PKI)
S/MIME or email certificates
Revocation: update the certificate revocation list (CRL) or OCSP
Certificate inventory (EV-D30): update to show certificate revoked
and revocation date
STEP 8 — DNS and network access confirmation
Action: Verify supplier IP ranges / hostnames can no longer access our systems
Who: IT Operations
Timeline: Within 24 hours of Steps 1–7
If supplier VPN or IP allowlisting was used:
Remove supplier IP ranges from firewall allowlists
Remove VPN gateway accounts
Verify that connections from supplier IP ranges are now rejected
at the perimeter (firewall deny log should show rejections)
STEP 9 — EV-D04 leaver record completed
Action: Complete the supplier exit section of the JML leaver record
Who: CISO (signs off); IT Operations (completes the technical section)
Timeline: Within 5 business days of the access revocation
The EV-D04 supplier exit record must include:
Supplier name and engagement reference
Each individual whose access was revoked: name, account UPN, revocation date
Revocation method for each access type
Confirmation that all seven steps above were completed with dates
Post-deactivation SIEM check result (see Step 10)
CISO sign-off
STEP 10 — Post-revocation SIEM review
Action: Review SIEM logs for any access events after the revocation timestamp
Who: Security Analyst
Timeline: Within 24 hours of Steps 1–7
Query: sign-in logs for all revoked accounts; access events from
supplier IP ranges; VPN connection attempts from supplier accounts
Expected result: zero successful authentications after the revocation
timestamp for any revoked account
If any successful authentication appears after revocation:
This is a Critical finding — investigate immediately
Possible causes: account not fully disabled; parallel account not
captured in the access inventory; token not revoked; session cached
Escalate to CISO immediately; treat as a potential security incident
SIEM review result documented in EV-D04
4.2 — Account retention and deletion after exit
Supplier accounts are handled identically to internal leaver accounts:
- Disabled state: Accounts are disabled immediately on exit. They are not deleted at this stage.
- 90-day retention: Disabled accounts are retained for 90 days in Entra ID. During this period, the sign-in history and audit trail are preserved. This period may be needed if: an incident investigation arises that requires examining what the account did; the exit is contested; or a regulatory authority asks about the supplier's activities.
- Permanent deletion: After 90 days, the account is permanently deleted and the UPN is permanently retired (not reassigned to another person or another supplier).
- Service account deletion: Service accounts created for the supplier are deleted immediately on exit (not held for 90 days), unless they are needed for forensic investigation. Confirm with the CISO before deleting service accounts during an emergency exit.
Section 5 — Ongoing confidentiality obligations
5.1 — What survives the end of the engagement
The end of a contract does not end the supplier's security obligations. Several obligations persist after the engagement closes, often for years. This section explains which obligations survive and for how long.
The following obligations continue after the engagement ends:
Confidentiality
The confidentiality obligation in your NDA and main contract survives termination. This typically means that for a defined period after the engagement (often 5 years, or for an indefinite period for trade secrets and CUI), you must continue to protect our confidential information as if the engagement were still active. You may not use our information for competitive purposes, share it with third parties, or publish it in any form.
The specific survival period is in your contract. If you are unsure what it says, contact the CISO. Do not assume confidentiality ends when the contract does.
CUI protection — no end date
The obligation to protect CUI does not have a contractual expiry date. DFARS §252.204-7012 obligations survive the contract. If you hold copies of our CUI after an engagement (which you should not, by virtue of the data deletion requirements in Section 2), those copies remain subject to the full NIST SP 800-171 protection requirements regardless of how long ago the contract ended.
If you ever discover, after an engagement has ended, that you have retained copies of our CUI that were not deleted during the exit process, you must notify the CISO immediately. Discovering a residual copy years later is not a breach in itself — failing to notify us when you discover it would be.
OFFICIAL information — no end date (while data is held)
The HMG classification marking on OFFICIAL information is not removed by the passage of time or the end of a contract. If you hold copies of our OFFICIAL data (which you should not), the handling requirements remain in force. Notify the CISO if you discover residual OFFICIAL data after an engagement closes.
Personal data — ongoing until certified deleted
Your obligations as our data processor under UK GDPR Article 28 survive termination of the main contract until you have confirmed in writing (via the certificate of deletion in Section 2.5) that all personal data has been deleted or returned. Until that confirmation is provided, you remain our processor for that data and your Article 28 obligations remain in force.
If you are legally required to retain certain personal data after the contract end (for example, by your own regulatory obligations as an employer), you must tell us what data you are retaining, under what legal basis, and for how long. You cannot retain our personal data beyond the period required by law and you cannot use it for any other purpose.
Incident reporting — 12 months post-exit
For 12 months after the engagement ends, if you discover a security incident that you believe may have affected data you held for us during the engagement — including data you have since deleted — you must still notify us. An incident discovered post-exit that involved historical exposure of our data may affect our regulatory reporting obligations and our risk assessments. Our CISO contact details remain available at the bottom of this page.
Audit rights — duration of the contract records requirement
Our right-to-audit clause (explained in the Supplier Assurance and Evidence Submission page) survives termination for the same period as our contract record-keeping obligations. In practice this means we retain the right to verify your data deletion and handling procedures for up to 3 years after the engagement ends, or for longer if required by our regulatory obligations (DFARS records, for example, must be kept for 5 years).
5.2 — Post-exit confidentiality declaration
At the point of exit, we ask your CISO (or equivalent authority) to sign a post-exit confidentiality declaration. This is not a new obligation — it is a confirmation of obligations that already exist in your contract. It serves as a reference point for your own compliance programme and as evidence for our ISO 27001 Annex A 6.5 (information security in employment termination) and A.5.19 (supplier relationships) controls.
POST-EXIT CONFIDENTIALITY DECLARATION
From: [Supplier company name]
To: [Organisation name] — CISO
Engagement ref: [SR-YYYY-NNN]
Engagement period: [Start date] to [End date]
I, [Name, Role], on behalf of [Supplier company], confirm that:
1. We understand and accept that our confidentiality obligations under
the contract dated [contract date] and the NDA dated [NDA date]
(where applicable) survive the termination of our engagement and
remain in force for the periods specified in those documents.
2. We have communicated our ongoing confidentiality obligations to all
individuals who worked on this engagement.
3. We have deleted or returned all [Organisation name] data in our
possession in accordance with the data resolution requirements
confirmed in our Certificate of Deletion dated [DATE].
4. If we discover any residual copy of [Organisation name]'s data
after the date of this declaration, we will notify [Organisation name]
CISO immediately and will take steps to delete that data.
5. For a period of 12 months following the end of our engagement, we
will notify [Organisation name] CISO of any security incident that
may have affected data we held during our engagement.
6. We will not use any information about [Organisation name]'s systems,
security architecture, or compliance posture obtained during our
engagement for any purpose other than delivering our contracted
services — including after the engagement has ended.
Signed: _______________________ Date: ____________________________
Name: _________________________ Role: ____________________________
Company: ____________________________________
Return to: [ciso@organisation.com]
Subject: POST-EXIT DECLARATION — [Your company name] — [Engagement ref]
Section 6 — DEFSTAN and CMMC specific exit obligations
6.1 — DEFSTAN-specific exit requirements
When an engagement involving OFFICIAL data under a DEFSTAN contract ends, the CISO must notify the contracting authority. This is a DEFSTAN obligation, not just internal policy.
What we notify the contracting authority:
- The name of the supplier whose engagement has ended
- The date access was revoked
- Confirmation that data resolution has been completed (once the certificate of deletion is received)
- The names of any individuals from the supplier who held BPSS screening or SC clearance under the contract — the contracting authority maintains its own records
What the supplier must provide to support DEFSTAN exit:
For DEFSTAN-scoped engagements, the certificate of deletion must explicitly confirm that OFFICIAL information has been deleted, and must identify the specific data destruction or deletion method. A generic deletion certificate without this specificity is not sufficient for DEFSTAN purposes.
If the engagement involved SC-cleared individuals from the supplier, the CISO will confirm the clearance hold position with UKSV — clearances held for our engagement may need to be reviewed or terminated as part of the exit.
6.2 — CMMC and DFARS specific exit requirements
When a supplier who has handled CUI exits, the data resolution obligation is a DFARS obligation as well as a contractual one. CUI that is not deleted or returned at engagement end remains subject to NIST SP 800-171 protection requirements wherever it sits.
What we need from the supplier at CUI exit:
-
The certificate of deletion must specifically confirm that CUI has been deleted, stating the CUI categories that were held and the deletion method applied.
-
For any CUI held in cloud storage: confirmation that the cloud storage has been purged and that customer-managed encryption keys have been rotated or deleted.
-
For any ITAR or EAR-controlled CUI: confirmation that individuals who had access to export-controlled technical data were US persons (or confirmed under an appropriate licence), and confirmation that no copies of export-controlled technical data remain with the supplier.
-
For the backup purge timeline: a specific date by which all backup copies of CUI will be purged (not just "we will purge it eventually"). If this date is more than 90 days from the exit date, contact the CISO — this is a DFARS risk that needs to be assessed.
Section 7 — Exit security checklist
This checklist is completed jointly by our CISO, IT Operations, and the commercial team for every supplier exit. One checklist per supplier engagement. Copy this checklist to a new child page at: EV-C → Risk Management → Supplier Assessments → [Supplier name] → Exit Checklist [YYYY-MM]
Part A — Exit initiation (CISO section)
SUPPLIER EXIT CHECKLIST — PART A: INITIATION
Engagement reference: SR-[YYYY]-[NNN]
Supplier name: _________________________________________________
Exit type: ☐ Planned (contract end) ☐ Emergency ☐ Partial
☐ Individual departure ☐ Scope reduction
Exit trigger date: ________________________________________________
Final access date: ________________________________________________
(The date after which no access should be possible)
CISO lead: ________________________________________________
☐ A.1 Commercial team has confirmed the exit and provided:
Contract reference: ___________________________________________
Final contract date: ___________________________________________
Reason for exit: ____________________________________________
(document; do not leave blank — needed for risk assessment)
☐ A.2 Exit type determined and timeline set:
□ Planned — 30-day notice period — data inventory due by: [DATE]
□ Emergency — same-day actions — access suspended: [TIME] [DATE]
□ Individual departure — confirm remaining individuals' access
is still appropriate
☐ A.3 Data classification confirmed — what data did this supplier hold?
☐ Internal only
☐ Official (DEFSTAN notification required — A.6 below)
☐ CUI (DFARS exit requirements apply — A.7 below)
☐ Personal data (DPA exit obligations apply — A.8 below)
☐ No classified data (onboarding review to confirm)
☐ A.4 Supplier notified of exit requirements
Sent: exit notification email to [supplier CISO name] on [DATE]
Email included: link to this page; data inventory template;
certificate of deletion template; timeline for completion
Supplier acknowledged: ☐ Yes Date: ________ ☐ Pending
☐ A.5 Asset register reviewed (EV-D22)
Items issued to supplier: [N items — list below]
_____________________________________________________________
Items to be returned: [N] — return deadline: [DATE]
Items confirmed returned: [N of N] — all returned: ☐ Yes ☐ No
☐ A.6 DEFSTAN contracting authority notification (if OFFICIAL data)
☐ Not required — engagement did not involve OFFICIAL data
☐ Required — notification sent to: [name] on [DATE]
Notification content: supplier exit; date; data resolution status
Contracting authority acknowledged: ☐ Yes ☐ Pending
☐ A.7 CMMC / DFARS specific actions confirmed (if CUI was held)
☐ Not required — engagement did not involve CUI
☐ CUI exit requirements communicated to supplier (Section 6.2)
☐ Backup purge timeline confirmed: all CUI deleted by [DATE]
☐ ITAR/EAR confirmation received (if applicable): ☐ Yes ☐ N/A
☐ A.8 DPA exit obligations confirmed (if personal data was processed)
☐ Not required — no personal data processed under DPA
☐ DPA exit obligations communicated to supplier
☐ Certificate of deletion required (deadline: [DATE])
☐ Sub-processor data also addressed: ☐ Yes ☐ N/A
CISO sign-off on Part A: _________________________ Date: _____________
Part B — Access revocation (IT Operations section)
SUPPLIER EXIT CHECKLIST — PART B: ACCESS REVOCATION
☐ B.1 All Entra ID / AD accounts disabled (not deleted)
Date/time of disabling: ______________________________________
Accounts disabled (list each UPN):
_____________________________________________________________
_____________________________________________________________
Disabled by: [IT Operations engineer name]
☐ B.2 Active sessions revoked (Revoke-MgUserSignInSession)
Date/time: _________________________________________________
Completed for all accounts: ☐ Yes
Verified: no active sessions in Entra ID sign-in logs
after revocation time: ☐ Confirmed
☐ B.3 MFA methods removed from all accounts
Date: ______________________________________________________
Methods removed: ☐ All accounts confirmed cleared
☐ B.4 VPN access removed
Removed from VPN group(s): ☐ Confirmed
VPN connection test (confirm blocked): ☐ Confirmed
Date/time: ________________________________________________
☐ B.5 ACS card(s) deactivated (on-site access)
☐ Not applicable — no on-site access was granted
☐ Cards deactivated in ACS console: ☐ All cards
Cards deactivated: [list card numbers] on [DATE/TIME]
Cards returned: ☐ Yes — confirmed by: ______________________
☐ No — marked as lost in ACS; no reissue
Zone 3 access list updated (EV-D23): ☐ Confirmed ☐ N/A
☐ B.6 Application-specific access removed
(Review EV-D03 onboarding record for full list)
☐ Document management system: [system name] — removed: [DATE]
☐ ITSM / ticketing system: removed: [DATE]
☐ Code repositories: removed: [DATE]
☐ Cloud consoles (AWS / Azure / GCP): removed: [DATE]
☐ Monitoring / SIEM access: removed: [DATE]
☐ Network management systems: removed: [DATE]
☐ Other [specify]: ________________________________ removed: [DATE]
☐ All items confirmed: no remaining application access
☐ B.7 Certificates revoked
☐ Not applicable — no certificates were issued to this supplier
☐ VPN client certificates: revoked on [DATE]
☐ Device identity certificates: revoked on [DATE]
☐ S/MIME / email certificates: revoked on [DATE]
☐ CRL / OCSP updated: ☐ Confirmed
☐ EV-D30 certificate inventory updated: ☐ Confirmed
☐ B.8 Network / firewall access confirmed removed
☐ Not applicable — no IP allowlisting was in place
☐ Supplier IP ranges removed from firewall rules: [DATE]
☐ Firewall deny log confirms rejections from supplier IPs:
☐ Confirmed — checked on [DATE] by [name]
☐ B.9 EV-D04 leaver record created
Record reference: _________________________________________
All revocation steps documented with dates: ☐ Confirmed
Filed at: EV-D → Access Control → JML Log → Leavers
☐ B.10 Post-revocation SIEM check
Checked on [DATE] by: [Security Analyst name]
Result: ☐ Zero successful authentications after revocation
☐ Anomalous activity found — escalated to CISO: [DATE]
SIEM check result documented in EV-D04: ☐ Confirmed
IT Operations sign-off on Part B: ________________________ Date: _______
IT Manager confirmation: __________________________________ Date: _______
Part C — Data resolution (CISO section, with supplier confirmation)
SUPPLIER EXIT CHECKLIST — PART C: DATA RESOLUTION
☐ C.1 Data inventory received from supplier
Received: ☐ Yes Date: ______________________________________
Submitted on time (within 10 business days): ☐ Yes ☐ No
Data inventory is complete and plausible: ☐ Yes ☐ No — [describe]
☐ C.2 Data resolution method confirmed with supplier
☐ Return — secure transfer to us by [DATE]
☐ Secure deletion — deadline [DATE]; certificate required by [DATE]
☐ Mixed — [specify what is returned vs what is deleted]
☐ C.3 Data return confirmed (if applicable)
☐ Not applicable — supplier is deleting, not returning
☐ Data returned via: [method] on [DATE]
☐ Return verified: contents confirmed, no corruption: ☐ Yes
☐ Supplier confirmed deletion of their copies after return:
☐ Confirmed in writing on [DATE]
☐ C.4 Certificate of deletion received
☐ Not yet due — deadline: [DATE]
☐ Received on [DATE] — reviewed by CISO: ☐ Yes
☐ Certificate covers all data categories:
☐ Internal ☐ Official ☐ CUI ☐ Personal data
☐ Certificate signed by appropriate authority: ☐ Yes ☐ No
☐ Certificate filed at: EV-C → [Supplier] → Exit → CertDeletion_[DATE]
☐ C.5 Backup purge confirmed
☐ Supplier uses no backup system that held our data — N/A
☐ Backup purge completed on [DATE] — confirmed in writing: ☐ Yes
☐ Backup purge in progress — expected completion: [DATE]
(monitor and update this item when confirmed)
☐ C.6 Personal data DPA deletion confirmed
☐ No personal data was processed under a DPA — N/A
☐ DPA Article 28(3)(g) deletion confirmed in writing: ☐ Yes
Date of written confirmation: __________________________________
☐ Sub-processor deletion confirmed: ☐ Yes ☐ N/A
☐ C.7 Physical media destruction confirmed
☐ No physical media was held by supplier — N/A
☐ Physical media destroyed — destruction certificate received: ☐ Yes
Certificate covers each item with serial number: ☐ Yes ☐ No
Filed at: EV-C → [Supplier] → Exit → MediaDestructionCert_[DATE]
☐ Printed documents destroyed — written confirmation received: ☐ Yes
☐ C.8 Sub-contractor data resolution confirmed
☐ No sub-contractors held our data — N/A
☐ Supplier confirmed all sub-contractor data resolved:
For each sub-contractor: [name] — resolved by [method] on [DATE]
☐ All sub-contractor resolutions confirmed
☐ C.9 CMMC-specific deletion confirmed (if CUI was held)
☐ Not applicable — no CUI held by supplier
☐ CUI deletion specifically confirmed in certificate: ☐ Yes
☐ Backup purge timeline for CUI confirmed (max 90 days): ☐ Yes
☐ ITAR/EAR controlled data disposal confirmed: ☐ Yes ☐ N/A
CISO sign-off on Part C: __________________________ Date: _____________
(C.4 and C.9 may be signed after receipt of the certificate if not yet received)
Part D — Supplier post-exit obligations (final confirmation)
SUPPLIER EXIT CHECKLIST — PART D: FINAL CONFIRMATION
☐ D.1 Post-exit confidentiality declaration received and signed
Signed by: [Name, Role] on [DATE]
Filed at: EV-C → [Supplier] → Exit → ConfidentialityDeclaration_[DATE]
☐ D.2 Supplier register updated
☐ Supplier record status changed to: "Engagement ended [DATE]"
☐ Critical supplier register updated (removed or status changed)
☐ Management-facing view updated (Supplier Governance page)
☐ D.3 Ongoing obligations briefed to supplier
☐ Supplier CISO confirmed they understand ongoing confidentiality
obligations and the 12-month post-exit incident reporting obligation
☐ D.4 DEFSTAN contracting authority exit notification
☐ Not required
☐ Notification sent: [DATE] — acknowledged: ☐ Yes ☐ Pending
☐ D.5 ISO 27001 evidence update
☐ ISO 27001 SoA updated if this supplier was part of scope
☐ Risk register reviewed: any risks associated with this supplier
relationship closed or updated
☐ D.6 Exit review (for Critical-tier suppliers and emergency exits)
☐ Standard exit — no formal review required
☐ Exit review conducted on [DATE] with [participants]
☐ Lessons from this exit applied to onboarding procedures: ☐ Yes ☐ N/A
☐ D.7 All exit documents filed
EV-C → Risk Management → Supplier Assessments → [Supplier name] → Exit
Documents filed:
☐ Exit checklist (this document)
☐ Data inventory from supplier
☐ Certificate of deletion (when received)
☐ Physical media destruction certificate (if applicable)
☐ Post-exit confidentiality declaration
☐ DEFSTAN notification confirmation (if applicable)
☐ EV-D04 leaver record references
☐ SIEM post-revocation check result
CISO final sign-off on complete exit:
All mandatory items confirmed: ☐ Yes ☐ Some items pending (see notes)
Outstanding items with deadlines: _____________________________________
CISO name: ___________________________ Date: _______________________
Commercial Director confirmation (for formal contract exits):
Commercial obligations resolved: ☐ Yes
[Director name]: ____________________ Date: ________________________
Section 8 — Contacts for supplier exit queries
If you are a supplier with questions about your exit obligations:
CISO: [CISO name]
Email: [ciso@organisation.com]
Phone: [CISO direct line]
Please use the following subject line for email:
SUPPLIER EXIT — [Your company name] — [Engagement reference]
For data deletion certificate submission:
Email: [ciso@organisation.com]
Subject: CERTIFICATE OF DELETION — [Your company name] — [Engagement ref]
For post-exit confidentiality declaration submission:
Email: [ciso@organisation.com]
Subject: POST-EXIT DECLARATION — [Your company name] — [Engagement ref]
For equipment return arrangements:
IT Manager: [IT Manager name]
Email: [itmanager@organisation.com]
Phone: [IT Manager direct line]
For commercial and contractual queries at exit:
Commercial Director: [Name]
Email: [commercial@organisation.com]
Phone: [commercial direct line]
Confluence page version and review
Evidence filing locations:
Exit checklists: EV-C → Risk Management → Supplier Assessments
→ [Supplier name] → Exit → ExitChecklist_[YYYY-MM]
Certificates of deletion: EV-C → Risk Management → Supplier Assessments
→ [Supplier name] → Exit → CertDeletion_[DATE]
Media destruction certs: EV-C → Risk Management → Supplier Assessments
→ [Supplier name] → Exit → MediaDestructionCert_[DATE]
Post-exit declarations: EV-C → Risk Management → Supplier Assessments
→ [Supplier name] → Exit → ConfidentialityDeclaration_[DATE]
EV-D04 leaver records: EV-D → Access Control → JML Log → Leavers
Retention:
Exit checklists and supporting documents: 3 years from exit date
DFARS-related exit records: 5 years from exit date
DEFSTAN-related exit records: duration of contract + 3 years post-contract
Certificates of deletion (CUI, OFFICIAL, personal data): 3 years minimum;
DFARS: 5 years; DEFSTAN: per contract terms
Review cycle: Annual — reviewed alongside the Supplier Onboarding page
and Policy 09 (Supplier Security Policy)
Page owner: CISO
Questions: [ciso@organisation.com]
| Version | Date | Prepared by | Key changes |
|---|---|---|---|
| 1.0 | [DATE] | CISO | Initial publication |