Supplier Data Handling and Classification Rules
Confluence page header
Page title: Data Handling and Classification Rules for Suppliers
Parent: ISMS Home → 09 · Supplier Security Policy
SCM variant: isms-all-staff (read — for staff sharing data with suppliers)
isms-management (read)
isms-security (full access — CISO maintains)
isms-it-staff (read)
Page owner: CISO
Last reviewed: [DATE]
Next review: Annual — aligned with Supplier Security Policy review and
each time a new data category enters scope
Related pages: Supplier Security Obligations (standard-tier)
Critical Supplier Security Obligations (critical-tier)
Supplier Onboarding (how access is granted)
04 · Information Classification and Handling Policy (internal)
EV-C → Risk Management → Supplier Assessments (evidence)
Who this page is for and how to read it
This page has two primary audiences.
Suppliers: If you are a supplier or contractor working with us, this page tells you what categories of information you may encounter, what the handling rules are for each category, and what specific obligations apply to you by law or by contract. Read Sections 1 through 4 fully before your engagement begins. If you encounter information in your work that you are unsure how to handle, the rule is: stop and ask the CISO before doing anything with it. The CISO contact is at the bottom of this page.
Internal staff: If you are responsible for sharing information with a supplier — sending files, granting access, briefing a contractor on a project — this page confirms what you can share, at what classification level, and what must be in place before sharing occurs. Refer to Section 5 for the process you must follow before sharing any classified information externally.
The data handling rules on this page apply alongside — not instead of — the internal data classification and handling rules in Policy 04 (Information Classification and Handling Policy). For any situation not covered here, Policy 04 is the governing document.
Section 1 — Data categories you may encounter
The organisation handles several categories of information, each with its own classification and regulatory regime. Not all suppliers will encounter all categories. Your contract and your CISO engagement letter will specify which categories are relevant to your engagement. This section explains what each category is, where it comes from, and what makes it legally and contractually significant.
1.1 — PUBLIC
What it is: Information that is publicly available or that the organisation has deliberately published. This includes our website content, published marketing materials, public product documentation, job advertisements, and information that has been approved for public release.
Where you will encounter it: Pre-sales conversations, public tenders, publicly available documentation.
Why it matters: No special handling required. No confidentiality obligation unless your contract includes general confidentiality provisions that extend to commercially sensitive discussions that happen to involve public information.
Regulatory regime: None specific to this category.
1.2 — INTERNAL
What it is: Information that is not publicly available and that the organisation expects to be treated as commercially confidential. This includes internal procedures, financial projections, commercial terms and pricing, project plans, staff information below PERSONAL DATA classification, and technical specifications that are not covered by CUI or OFFICIAL markings.
INTERNAL is the default classification for any information we share with you that does not carry a more specific marking. If you receive a document from us with no classification marking and you are uncertain, treat it as INTERNAL until you have confirmed with the CISO.
Where you will encounter it: Contract documents, project briefs, internal procedures shared to enable your work, meeting notes, technical specifications.
Why it matters: You are bound to protect INTERNAL information under the confidentiality provisions of your NDA or main contract. Disclosure of INTERNAL information to third parties, including other clients you work with, is a breach of contract regardless of how the information reached you.
Regulatory regime: Contract law and confidentiality obligations in your NDA or main contract. No statutory regime applies specifically to this category.
1.3 — OFFICIAL
What it is: Information handled under the UK Government Security Classifications (GSC) scheme at the OFFICIAL tier. OFFICIAL information encompasses the vast majority of information that UK government departments produce and handle in their day-to-day work. When we process or handle OFFICIAL information, it is because we hold contracts with UK government departments, most commonly the Ministry of Defence, under our DEFSTAN 05-138 obligations.
OFFICIAL information is not secret. It is not OFFICIAL-SENSITIVE unless it carries that additional marking. However, it is government information and its mishandling creates legal and contractual consequences for us and, through our contract with you, for you.
How to recognise it: Documents may be marked "OFFICIAL" in the header and footer. In practice, some working documents in government contract contexts are not explicitly marked — if you are working on a MOD contract with us and the information relates to that contract, assume OFFICIAL unless told otherwise.
Where you will encounter it: Suppliers engaged on our MOD contracts under DEFSTAN 05-138; any supplier who accesses our systems or data in connection with UK government contract delivery.
Why it matters: Our DEFSTAN contracts impose specific obligations about how OFFICIAL information is handled. A breach of those obligations by one of our suppliers is a breach by us. The contracting authority can inspect our supply chain security practices and may terminate our contract if we cannot demonstrate that our suppliers are meeting OFFICIAL handling requirements.
Regulatory regime: HMG Government Security Classifications Policy; DEFSTAN 05-138 (the applicable profile is in your contract schedule); our Supplier Security Obligations or Critical Supplier Security Obligations page (depending on your tier).
1.4 — OFFICIAL-SENSITIVE
What it is: The OFFICIAL-SENSITIVE marking is a subset of OFFICIAL. It indicates that the information requires enhanced handling because of its particular sensitivity — typically because disclosure could cause harm to an individual, to an investigation, to commercial interests, or to national interests at a level that standard OFFICIAL protection would not adequately address.
How to recognise it: Documents will be marked "OFFICIAL-SENSITIVE" in the header and footer. Some documents may additionally carry a descriptor after the marking (for example "OFFICIAL-SENSITIVE: PERSONAL") indicating the specific reason for the additional sensitivity.
Where you will encounter it: Less common than OFFICIAL in supplier engagements. If you encounter OFFICIAL-SENSITIVE information in your work, this should have been specifically scoped in your contract and your access arrangements. If you receive OFFICIAL-SENSITIVE information unexpectedly — for example, a document you receive turns out to be marked OFFICIAL-SENSITIVE when you were not expecting it — do not process, copy, or transmit it. Notify the CISO immediately.
Regulatory regime: As for OFFICIAL above, with additional restrictions that will be specified in your contract.
1.5 — CUI (Controlled Unclassified Information)
What it is: CUI is an information category defined by the United States National Archives (NARA) under Executive Order 13556. CUI is information that the US federal government creates or possesses, or that an entity creates or possesses for or on behalf of the government, that must be handled using safeguarding or dissemination controls consistent with applicable law, regulations, and government-wide policies.
In practical terms, CUI is the information category that our US Department of Defense contracts require us to protect. It is the US government's equivalent of the UK's OFFICIAL tier, though the two systems are not perfectly aligned and should not be treated as interchangeable.
CUI covers a wide range of information types — technical drawings, specifications, proprietary business information, export-controlled technical data, personnel information, and others. The specific CUI categories relevant to our contracts are specified in our contracts and in our System Security Plan (SSP). If you are engaged on work that involves our DoD contracts, the CISO will specify which CUI categories you may encounter.
How to recognise it: CUI is marked on documents using the CUI marking system. A document containing CUI will display "CUI" prominently at the top and bottom of each page. Some CUI documents also carry a category designation (for example, "CUI // SP-ITAR" indicating that the CUI also falls under ITAR export control regulations). Unmarked information that you believe is CUI should be treated as CUI until confirmed — contact the CISO.
Where you will encounter it: Suppliers engaged on our work with US DoD prime contractors or directly on DoD contracts; suppliers who access our systems or data in connection with US defence contract delivery.
Why it matters: CUI is subject to DFARS §252.204-7012 and NIST SP 800-171. A cyber incident involving CUI triggers our 72-hour mandatory reporting obligation to DoD. If the incident involves your systems, we need you to notify us within 2 hours so we can meet our own clock. Mishandling CUI — including sharing it with unauthorised parties, failing to protect it adequately, or allowing it to be accessed by non-US-person nationals without proper export authorisation — creates criminal and civil liability for the parties involved.
Regulatory regime: NIST SP 800-171 Rev 2 (the technical security standard); DFARS §252.204-7012 (the contract clause that imposes the obligations); 32 CFR Part 2002 (the CUI regulation); potentially ITAR (International Traffic in Arms Regulations) or EAR (Export Administration Regulations) if the CUI is export-controlled.
1.6 — PERSONAL DATA
What it is: Personal data is any information that relates to an identified or identifiable living individual. Under UK GDPR (and its predecessor GDPR), "identifiable" is interpreted broadly — a person can be identified directly (by name) or indirectly (by a combination of information such as job title, employer, and location that, together, point to a specific person).
Personal data we may share with suppliers includes: employee names, contact details, and employment information; customer or client contact details; supplier contact details; and in some circumstances, special category data (health information, criminal records data, or biometric data).
How to recognise it: There is no marking system for personal data equivalent to CUI or OFFICIAL markings. Any information that contains names, contact details, identifiers (like employee numbers or national insurance numbers), or other information about individuals should be treated as personal data. If you are unsure whether information you have received constitutes personal data, treat it as personal data and seek guidance.
Where you will encounter it: Any supplier who processes HR data, customer data, or any database or file that contains information about people. Even technical log files can contain personal data (IP addresses are personal data in many circumstances).
Why it matters: UK GDPR imposes strict obligations on both the organisation (as data controller) and on you (as data processor, if you process personal data on our behalf). Non-compliance with UK GDPR can result in ICO enforcement action and fines of up to £17.5 million or 4% of global annual turnover, whichever is higher. Personal data breaches must be reported to the ICO within 72 hours if they are likely to result in a risk to individuals' rights and freedoms. You must notify us within 24 hours so we can assess and meet our own notification obligation.
Regulatory regime: UK GDPR; Data Protection Act 2018; ICO guidance. If your organisation is based in the EU, GDPR may also apply. If personal data is transferred outside the UK or EEA, transfer safeguards apply.
1.7 — COMMERCIALLY SENSITIVE
What it is: Information about our commercial relationships, pricing, contract terms, strategic plans, or other business information that, if disclosed, could damage our competitive position or our relationships with customers, partners, or suppliers.
This is not a formal regulatory category but it is a contractual confidentiality category that appears in most supplier contracts.
Where you will encounter it: Commercial discussions, pricing documents, contract negotiations, business case documentation.
Regulatory regime: Contract law and your NDA or main contract.
Section 2 — Handling requirements by data category
The following tables define the specific handling requirements for each data category. Where requirements differ for Standard-tier and Critical-tier suppliers, this is indicated. Review your tier designation in your engagement documentation if you are unsure which column applies to you.
2.1 — Storage requirements
DATA STORAGE REQUIREMENTS
Category Standard-tier supplier Critical-tier supplier
──────────────────────────────────────────────────────────────────────────────────────
PUBLIC No special requirement No special requirement
INTERNAL Stored on your corporate IT Stored on your corporate IT
systems with access controls. systems with access controls.
Not in personal cloud storage. Not in personal cloud storage.
Not on personal devices. Not on personal devices.
OFFICIAL Stored on corporate systems with Stored on systems with full disk
access limited to individuals encryption (AES-256). Access
working on our contract. limited to individually named,
Not in personal cloud storage. BPSS-screened individuals.
Encrypted in transit. Storage must be UK or EEA only.
Not in personal cloud storage.
Client-side or customer-managed
keys if stored in cloud services.
OFFICIAL-SENSITIVE Consult CISO before storing. As OFFICIAL above, plus:
Only store if your contract Discuss with CISO before any
explicitly requires it. storage on your systems.
CUI Stored only on systems Stored on systems meeting NIST
meeting CE Plus minimum. SP 800-171 technical requirements.
AES-256 encryption at rest. FIPS 140-2/3 validated modules.
Access limited to named, Storage in the US or approved
individually authorised persons. US-government-certified cloud
Not in personal cloud storage. (FedRAMP Authorized).
Not on unsupported OS. Client-managed encryption keys.
Personnel must be US persons
or have specific export authority
for ITAR/EAR-controlled CUI.
PERSONAL DATA Stored per your DPA obligations. As Standard-tier, plus:
(where you are UK or EEA data residency unless GDPR Article 32 technical
our processor) transfer safeguard is agreed. measures documented and auditable.
Access limited to authorised Data minimisation demonstrated.
processing personnel. Data subject rights capability.
COMMERCIALLY As for INTERNAL above. As for INTERNAL above.
SENSITIVE
──────────────────────────────────────────────────────────────────────────────────────
2.2 — Transmission requirements
DATA TRANSMISSION REQUIREMENTS
Category Method Prohibited methods
──────────────────────────────────────────────────────────────────────────────────────
PUBLIC Any method None
INTERNAL TLS-encrypted email or SFTP. Plain FTP. Plain HTTP.
Confirm receiving server Unencrypted email attachments.
supports TLS before sending. Consumer file sharing (WeTransfer
Do not send via consumer without encryption).
services without encryption.
OFFICIAL Encrypted email (TLS transport Plain FTP. Plain HTTP.
minimum; end-to-end preferred) Unencrypted email.
or SFTP or our approved secure Personal email accounts.
file transfer portal. Consumer file sharing services.
Encryption key/password sent SMS or instant messenger.
separately from the file.
OFFICIAL-SENSITIVE End-to-end encrypted email As OFFICIAL above, plus:
(S/MIME or PGP) or our approved TLS-only email is insufficient.
secure file transfer portal. End-to-end encryption is mandatory.
Confirm delivery method with
CISO before any transmission.
CUI Our approved secure file transfer Plain FTP, HTTP, email without
portal OR end-to-end encrypted encryption.
email (S/MIME or PGP with Personal email accounts.
our CA certificate). Consumer file sharing services.
FIPS-validated encryption. Non-FIPS-validated methods.
Over a FIPS-validated VPN USB without encryption.
if transmitted over networks Any method not pre-approved
we do not control. by our CISO in writing.
PERSONAL DATA Encrypted in transit (TLS Unencrypted transmission.
(where you are minimum). For bulk transfers of Personal email accounts.
our processor) personal data: SFTP or approved Consumer file sharing services.
encrypted portal. Confirm Transfer outside UK/EEA without
channel with CISO before an approved transfer mechanism.
first bulk transfer.
COMMERCIALLY TLS-encrypted email or SFTP. As for INTERNAL above.
SENSITIVE As for INTERNAL above.
──────────────────────────────────────────────────────────────────────────────────────
2.3 — Access control requirements
DATA ACCESS CONTROL REQUIREMENTS
Category Who may access Authentication requirement
──────────────────────────────────────────────────────────────────────────────────────
PUBLIC Anyone None
INTERNAL Individuals at your organisation Standard authentication on your
involved in our engagement. own systems.
OFFICIAL Named, individually authorised MFA required for any system
personnel who have completed access involving OFFICIAL data.
BPSS screening. No shared Individual named accounts only —
accounts. No generic accounts. no shared accounts.
OFFICIAL-SENSITIVE As OFFICIAL above. As OFFICIAL above, plus:
Principle of need-to-know Access logging required.
strictly applied.
CUI Named, individually authorised MFA required (FIDO2 for
personnel. US persons or privileged accounts, as required
persons with specific export by our Critical-tier obligations).
authorisation for export- Individual named accounts.
controlled CUI categories. Session recording for privileged
BPSS minimum (SC for higher access to CUI-scope systems.
sensitivity CUI).
PERSONAL DATA Personnel with a documented Access controls preventing
(where you are need to process that specific unauthorised access.
our processor) personal data. Access Access logging for audit trails.
minimised to the minimum
required for the processing
purpose.
COMMERCIALLY As for INTERNAL above. As for INTERNAL above.
SENSITIVE
──────────────────────────────────────────────────────────────────────────────────────
2.4 — Retention and destruction requirements
DATA RETENTION AND DESTRUCTION REQUIREMENTS
Category Maximum retention Destruction method
──────────────────────────────────────────────────────────────────────────────────────
PUBLIC As long as needed for the Standard disposal — no
engagement. No destruction special requirement.
requirement.
INTERNAL Duration of engagement plus Secure deletion (overwrite)
30 days for final handover. for digital. Cross-cut shred
Destroy within 30 days of (DIN P-4 minimum) for paper.
engagement end unless longer Written confirmation to CISO.
retention is required by law.
OFFICIAL As specified in your contract NIST SP 800-88 equivalent
or, where not specified, no for digital media.
longer than 12 months after Cross-cut or micro-cut shred
contract end. (DIN P-4 minimum) for paper.
Notify CISO before destroying. Certificate of destruction
required. Notify CISO.
OFFICIAL-SENSITIVE As OFFICIAL above. As OFFICIAL above. Destruction
Confirm retention period certificate required.
with CISO before retaining Confirm method with CISO
beyond contract end. before destruction.
CUI No longer than needed for the NIST SP 800-88 compliant
purpose of the contract. sanitisation for digital.
Must not retain CUI beyond ADISA-certified vendor
contract end without written preferred for disposal.
approval from our CISO. Certificate of destruction
Return or certify destruction listing individual asset
within 30 days of contract end. serial numbers. Required.
Backups: purge within 90 days.
PERSONAL DATA As specified in your DPA and our Secure deletion for digital.
(where you are data retention schedule. Destruction method specified
our processor) No longer than needed for the in your DPA. Written
processing purpose. Return confirmation to CISO that
or destroy per our instruction. all personal data has been
DPA obligations survive contract deleted or returned.
end until destruction confirmed.
COMMERCIALLY Duration of engagement plus As for INTERNAL above.
SENSITIVE 30 days for final handover.
──────────────────────────────────────────────────────────────────────────────────────
Section 3 — CUI obligations for US defence data
This section provides the full detail of what handling CUI means in practice for suppliers engaged on our US defence contract work. If your engagement does not involve CUI — if the CISO has confirmed that your work relates only to OFFICIAL, INTERNAL, or personal data — skip to Section 4. However, if you are in any doubt about whether your work may touch CUI, read this section.
3.1 — What CUI actually covers in our context
CUI is not a single information type. It is a family of categories defined in the NARA CUI Registry at archives.gov/cui. The CUI categories most commonly relevant to our defence contract work are:
CUI CATEGORY WHAT IT COVERS COMMON DOCUMENTS
────────────────────────────────────────────────────────────────────────────────────────
FEDCON Federal contract information Contract documents, SOWs,
(Federal Contract — information that is technical requirements from
Information) provided by or generated for US government contracts.
the government under a Includes information about
federal contract. contract performance.
CTI Controlled technical Technical drawings, designs,
(Controlled Technical information — technical data specifications, models,
Information) with military or space software code, and data with
application subject to direct military relevance.
controls under DoD Often the most sensitive
Instruction 5200.45. category in our context.
PRVCY Privacy data — information Personal data about
(Privacy) about individuals protected government personnel or
under federal privacy law. other individuals covered
by US federal privacy law.
PROPIN Proprietary business Commercially sensitive
(Proprietary Business information marked by the technical data, trade
Information) originator as proprietary secrets, and business
or submitted with the information submitted
expectation of protection. to or by the government.
ITAR / EAR Export-controlled technical Any technical data,
(handled separately) data under the International software, or hardware
Traffic in Arms Regulations subject to US export
or Export Administration control regulations.
Regulations. Special access controls
required — see 3.4.
Your CISO engagement letter will specify which CUI categories are relevant to your specific engagement. If you receive a document marked with a CUI category that was not specified in your engagement scope, do not process it — notify the CISO immediately.
3.2 — The NIST SP 800-171 requirement
NIST SP 800-171 is the US federal standard that specifies how contractors must protect CUI. It has 14 control families and 110 individual security requirements. As a Critical-tier supplier handling CUI on our behalf, you are required to implement all 110 requirements (or have a documented Plan of Action and Milestones for any requirements not yet fully implemented).
You are not required to certify against NIST 800-171 independently to work with us — we manage our own CMMC certification. However, we need evidence that you are implementing the standard and that your implementation is documented and assessed. We will review this evidence in your annual assurance questionnaire and assurance review meeting.
The 14 control families cover: Access Control (22 controls), Awareness and Training (3), Audit and Accountability (9), Configuration Management (9), Identification and Authentication (11), Incident Response (3), Maintenance (6), Media Protection (9), Personnel Security (2), Physical Protection (6), Risk Assessment (3), Security Assessment (4), System and Communications Protection (16), and System and Information Integrity (7).
The five control families most commonly found deficient in supplier assessments are: Access Control (particularly the segregation of duties and least privilege requirements), Audit and Accountability (logging and monitoring), Configuration Management (hardened baselines and change management), Identification and Authentication (MFA), and System and Information Integrity (patching and malware protection). Review your implementation of these families before your annual assurance review.
3.3 — CUI marking and identification
When we provide you with CUI, it should be marked. When you create information in connection with our DoD contract work, you may be creating CUI — and it should be marked by you.
Receiving marked CUI: If you receive a document from us marked "CUI" (or with a CUI category designation like "CUI // CTI"), the marking tells you that the document requires CUI-level protection from the moment you receive it. Store it, transmit it, and destroy it according to the CUI requirements in this page.
Receiving unmarked information that may be CUI: Not all information that qualifies as CUI will be marked. If you receive information in connection with our DoD contract work that you believe may be CUI but is not marked, treat it as CUI and notify the CISO. We will confirm the classification and provide a marked copy where appropriate.
Creating CUI: If your work for us involves creating documents, reports, or technical outputs in connection with our DoD contract, those outputs may be CUI — particularly if they contain technical specifications, contract performance data, or proprietary information. Apply the CUI marking to any document you create in connection with our DoD work. If you are unsure whether a specific document you are creating is CUI, ask the CISO before completing and distributing the document.
The CUI marking format: Apply "CUI" centred at the top and bottom of each page of any document you create that contains CUI. If the document contains a specific CUI category (for example, Controlled Technical Information), the format is "CUI // CTI" at the top and bottom. Do not use other classification markings (such as CONFIDENTIAL or SECRET) — these are different classification systems and are not appropriate for CUI.
3.4 — Export control obligations (ITAR and EAR)
If the CUI in your engagement is subject to export control under the International Traffic in Arms Regulations (ITAR) or Export Administration Regulations (EAR), additional access restrictions apply that override standard CUI handling rules.
ITAR-controlled CUI: ITAR regulates the export of defence articles, defence services, and related technical data listed in the United States Munitions List (USML). If information we share with you carries an ITAR marker ("CUI // SP-ITAR" or is described in your contract as ITAR-controlled), the following apply:
- Only US persons (US citizens, lawful permanent residents, or individuals granted protected status under 8 USC 1324b(a)(3)) may access ITAR-controlled technical data without an export licence
- Non-US-person employees at your organisation — even if they hold UK, EEA, or other nationality — may not access ITAR-controlled technical data without our CISO confirming that an export licence is in place or that a licence exemption applies
- You must notify the CISO of the nationality of every individual who will have access to ITAR-controlled CUI before granting that access
- Transmitting ITAR-controlled technical data to a non-US person, or to a location outside the US, is an export under ITAR — including sending an email, sharing a file, or showing a screen. Each of these acts requires a licence or exemption.
EAR-controlled CUI: The Export Administration Regulations control dual-use goods and technology listed in the Commerce Control List (CCL). The access restrictions are similar to ITAR but the specific requirements depend on the Export Control Classification Number (ECCN) of the controlled items. Contact the CISO before sharing any EAR-controlled CUI with any individual or location.
If you discover you may have shared ITAR or EAR-controlled CUI with an unauthorised person or location: Do not attempt to resolve this quietly. Contact the CISO immediately. Export control violations carry criminal penalties in both the US and the UK (under the Export Control Order 2008). Early disclosure is always better than late discovery.
3.5 — CUI incident reporting
The DFARS cyber incident reporting requirement is covered in the Critical Supplier Security Obligations page and in the Supplier Security Obligations page (Section 1.3). Here we summarise the specific CUI-related obligations:
When you must report: Any confirmed or suspected compromise, unauthorised access, exfiltration, or loss of CUI — including printed documents, digital files, or access credentials that could lead to CUI access. Report within 2 hours of discovery regardless of whether your investigation is complete.
What to report: The nature of the incident; when it was discovered; which systems and CUI categories were involved; what initial containment steps have been taken; the name of your incident lead.
Evidence preservation: Do not reimage, wipe, or modify any system involved in a CUI incident until we confirm that evidence preservation requirements are satisfied. DFARS §252.204-7012(f) requires that a forensic image of affected systems be provided to DoD. We need to manage that obligation — preserve first, then coordinate with us.
Export implications: A CUI incident involving ITAR or EAR-controlled technical data may also trigger export control notification obligations. Notify us so we can manage both the DFARS reporting and any export control notification together.
Section 4 — UK GDPR Article 28 processor obligations
4.1 — When Article 28 applies to you
If you process personal data on our behalf — meaning you handle, store, access, transmit, or otherwise work with personal data where we determine the purposes and means of that processing — you are acting as our data processor under UK GDPR Article 28.
Processing "on our behalf" means: we asked you to process the data; you are doing it for our purposes, not your own; and we have told you (or it is clear from the context) what to do with it.
Examples of supplier relationships that make you our processor:
- You provide managed IT services and in doing so access our email systems, which contain employee personal data
- You provide HR software or payroll processing services
- You provide customer relationship management services and our customer contact data is stored in your system
- You conduct background screening of our employees using personal data we provide to you
- You provide cloud storage where we store documents containing personal data
- You conduct security testing of our systems and in doing so access logs containing personal data
Examples of supplier relationships that do NOT make you our processor (you are an independent controller):
- You provide legal advice and in doing so hold personal data about the matter — you determine how you handle that data professionally and legally
- You are a recruitment agency and hold candidate data for your own recruitment business purposes, which you are also using to fill our vacancy
- You process your own employees' personal data to manage the people who work on our engagement — that is your employment data, not ours
If you are uncertain whether you are our processor: ask the CISO. Getting this wrong has real consequences — an organisation that acts as a processor without a signed DPA is in breach of UK GDPR regardless of whether the processing was otherwise lawful.
4.2 — What Article 28 requires
UK GDPR Article 28 requires that every relationship where a controller (us) uses a processor (you) to process personal data must be governed by a contract — the Data Processing Agreement (DPA). The DPA must include specific provisions set out in Article 28(3). These are not optional clauses — they are mandatory legal requirements.
The following is a plain-English description of what the DPA must contain:
Process only on our documented instructions. You may process personal data only in the ways and for the purposes we specify. If you believe our instruction would result in a breach of UK GDPR, you must tell us before proceeding. You must not process personal data for your own purposes, including for analytics, product improvement, or any commercial purpose.
Confidentiality of processing personnel. Your staff who process our personal data must be bound by confidentiality — either under an employment contract or a separate confidentiality obligation. You must ensure that only authorised personnel process our personal data.
Technical and organisational security measures. You must implement security measures appropriate to the risk, as required by Article 32. This includes pseudonymisation and encryption, ongoing confidentiality and integrity of processing systems, ability to restore data in the event of an incident, and regular testing of security measures. The specific measures must be described in your DPA or in a security schedule attached to it.
Sub-processor controls. You may not engage another sub-processor to process our personal data without our prior written authorisation. You may use a general authorisation from us that covers categories of sub-processors, but you must notify us of any intended addition or replacement and give us the opportunity to object.
Data subject rights assistance. You must assist us in responding to data subject rights requests — requests from individuals to access, correct, delete, or port their personal data. When you receive a request that appears to be from one of our data subjects (one of our employees, customers, or others whose data we hold), you must forward it to us within 5 days. Do not refuse it or respond to it directly unless we have explicitly asked you to handle it on our behalf.
Breach notification. You must notify us of any personal data breach within 24 hours of your becoming aware of it. A personal data breach is any accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to personal data you process on our behalf. This 24-hour obligation is tighter than our 72-hour ICO obligation — it gives us time to assess and report.
Deletion or return at contract end. At the end of our contract, you must (at our choice) delete or return all personal data. You must confirm in writing that deletion is complete. Unless you are legally required to retain the data, it must be deleted — not archived, not anonymised without confirmation, not simply removed from live systems while retained in backups.
Audit rights. You must make available to us all information necessary to demonstrate your compliance with Article 28, and must allow us or our designated auditors to audit your data processing activities on reasonable notice. We are unlikely to exercise this right routinely, but we must be contractually entitled to do so.
4.3 — Technical and organisational measures (Article 32)
Your DPA will require you to implement "appropriate technical and organisational measures" to protect personal data. For our engagements, we define the minimum measures as follows. These are the baseline — you may implement more stringent measures, but you must implement at least these:
TECHNICAL MEASURES — MINIMUM REQUIRED
Encryption in transit:
All personal data transmitted electronically must be encrypted in transit.
Minimum: TLS 1.2. TLS 1.3 preferred.
Unencrypted transmission of personal data is a breach of your DPA
and a potential ICO reportable incident.
Encryption at rest:
Personal data stored digitally must be encrypted at rest.
Minimum: AES-256 encryption.
Full disk encryption on any device that may hold personal data.
This includes laptops, mobile phones, backup media.
Access controls:
Access to personal data limited to personnel who need it for the
processing purpose. Role-based access controls enforced.
Access logging — who accessed what data, when, and from where.
MFA required for any system that stores or processes personal data
on our behalf.
Vulnerability management:
Systems processing our personal data must be patched within 14 days
of a Critical severity vulnerability being published.
Regular vulnerability scanning (minimum: monthly authenticated scan).
Supported operating systems only — no EOL OS on systems holding
our personal data.
Backup and recovery:
Regular backups of personal data with a tested recovery capability.
Backup data must be encrypted.
Recovery point objective (RPO) and recovery time objective (RTO)
appropriate to the criticality of the processing.
ORGANISATIONAL MEASURES — MINIMUM REQUIRED
Personnel:
Staff who process our personal data are trained in data protection
obligations at least annually.
Staff have read and understood your organisation's privacy policy
and acceptable use policy.
Disciplinary process in place for data protection policy violations.
Procedures:
Documented procedure for handling personal data breach incidents
(including the 24-hour notification obligation to us).
Documented procedure for handling data subject rights requests.
Documented procedure for data deletion or return at contract end.
Sub-processors:
Register of sub-processors used to process our personal data.
Written contracts with sub-processors containing equivalent obligations.
DPA-equivalent provisions flow down to all sub-processors.
Data protection contact:
A named person responsible for data protection compliance at your
organisation who can be contacted for DPA administration.
If your organisation is required to appoint a Data Protection Officer
under UK GDPR: their name and contact details must be provided.
Section 5 — The Data Processing Agreement process
5.1 — When a DPA must be in place
A DPA must be signed by both parties before any personal data is shared with you. There is no grace period, no provisional sharing arrangement, and no "we'll sort the DPA out later." Sharing personal data without a DPA in place is a breach of UK GDPR Article 28. The ICO does not accept "we were in the process of formalising the agreement" as a mitigating factor.
The CISO will identify whether a DPA is required as part of the supplier onboarding process. If the onboarding assessment identifies a DPA requirement, the DPA will be prepared and executed before access is granted.
If you have already been sharing personal data with us — or we with you — under an arrangement that does not have a signed DPA, contact the CISO immediately. We will prioritise getting the DPA in place. We prefer to resolve this proactively rather than have it surface in an incident investigation or an ICO enquiry.
5.2 — Our standard DPA
We maintain a standard DPA template that covers the Article 28(3) requirements and the technical and organisational measures specified in Section 4.3. For most supplier relationships, this standard template will be used without material modification.
The standard DPA is available from the CISO on request at [ciso@organisation.com]. Request it at the outset of engagement scoping — not after the contract is in negotiation.
5.3 — When a supplier proposes their own DPA
Some suppliers, particularly large cloud and technology vendors (infrastructure providers, SaaS platforms, managed service providers), have their own standard DPA that they offer to all customers. Whether we can accept a supplier-proposed DPA rather than our own depends on whether it meets the Article 28(3) requirements and the technical measure standards above.
Cloud service providers with publicly available DPAs: Major providers (Microsoft, Google, AWS, Salesforce, and similar) publish their DPAs. These typically meet the Article 28(3) requirements. The CISO will review and confirm acceptability.
Smaller suppliers proposing their own DPA: The CISO reviews the proposed DPA against the Article 28(3) checklist and the technical measures standard. If the supplier's DPA does not meet our requirements, the CISO will identify the gaps and negotiate the necessary additions.
A DPA that any supplier presents to us as "standard" or "non-negotiable" on the personal data protection provisions is not acceptable by default. Article 28(3) is not negotiable — the law requires those provisions to be in the contract. If a supplier refuses to include the Article 28(3) requirements, we cannot use that supplier for processing that involves personal data.
5.4 — Sub-processors — your obligations
If you engage sub-processors to process our personal data (for example, you use a cloud hosting provider to run the application in which our data is stored, or you use a support ticketing platform that may contain our data), you must:
Notify us before engaging the sub-processor. Either at the time you provide your list of current sub-processors (at onboarding) or before adding a new sub-processor. We have the right to object to sub-processors that we consider represent an unacceptable risk to our personal data.
Have a DPA-equivalent contract with each sub-processor. The obligations you are under in your DPA with us must flow down to your sub-processors. This includes: the instruction-only processing requirement; the security measures; the breach notification obligation; the audit right; and the deletion at contract end obligation.
Remain liable for your sub-processors. Under Article 28(4), if a sub-processor fails to fulfil its data protection obligations, you remain fully liable to us for the sub-processor's non-compliance. Engaging a sub-processor does not transfer your liability — it adds the sub-processor to the chain while you retain responsibility for that chain.
Provide us with your sub-processor list. Your annual assurance questionnaire asks for your sub-processor list. Keep it current. If you add or change a sub-processor during the year, notify us promptly.
5.5 — International data transfers
If you will transfer our personal data outside the UK or the EEA — including to your own offices, to sub-processors, or to cloud infrastructure located outside the UK/EEA — you must have an appropriate transfer mechanism in place.
For transfers from the UK to third countries (countries not covered by a UK adequacy regulation), the available transfer mechanisms include:
TRANSFER MECHANISM WHAT IT IS WHEN IT APPLIES
──────────────────────────────────────────────────────────────────────────────────────
UK adequacy A country the UK has Transfer to that country is
regulations confirmed has equivalent straightforward — no additional
data protection safeguards needed. Current list:
see ICO website (ico.org.uk).
UK International ICO-approved model clauses Most commonly used for transfers
Data Transfer incorporated into a to countries without UK adequacy.
Agreement (IDTA) contract between the Must be completed in full and
UK exporter and the signed. Available from ICO.
non-EEA importer.
UK Addendum to Used where the EU standard For suppliers using the EU SCCs
EU SCCs contractual clauses who also need UK transfer coverage.
(SCCs) are in use. ICO addendum appended.
Binding Corporate A group-wide commitment For multinationals transferring
Rules (BCRs) approved by a data within their own group of companies.
protection authority.
──────────────────────────────────────────────────────────────────────────────────────
US data transfers: The UK-US data bridge (adequacy) came into effect in 2023 for organisations certified under the UK Extension to the EU-US Data Privacy Framework. If your US organisation is certified under this framework, transfers to you from the UK can use this mechanism. If not, an IDTA or UK Addendum to EU SCCs is required.
Cloud infrastructure: If you use cloud infrastructure (AWS, Google Cloud, Azure, or others) with regions outside the UK/EEA, the cloud provider's DPA typically includes the IDTA or equivalent transfer mechanisms. Confirm with the CISO which cloud regions you use and which transfer mechanism is in place.
Any transfer of our personal data to a country or entity without an appropriate transfer mechanism in place is a breach of UK GDPR. Transfers without a mechanism are reportable breaches if personal data is actually transferred. Notify the CISO before any transfer arrangement changes.
Section 6 — Special situations
6.1 — Receiving a data subject rights request
If an individual contacts you directly believing that you hold their personal data and asking to exercise a UK GDPR right (access, erasure, rectification, portability, restriction, or objection), do not respond to the request directly. You are our processor — the individual's rights apply to us as the data controller.
Forward the request to the CISO at [ciso@organisation.com] within 5 business days of receiving it. Include a copy of the request and the date you received it. We have one month from the date of the original request to respond to the individual — the sooner you forward it, the more time we have.
If you receive a request that appears to be from one of our employees, former employees, or customers: forward it. If you receive a request that appears to be from someone who has no connection to our engagement (possibly sent in error): forward it anyway. We will determine whether the request is valid and respond accordingly.
6.2 — Receiving a regulatory or law enforcement request for personal data
If a regulatory authority (including the ICO), a court, or a law enforcement body serves you with a requirement to produce our personal data:
- Do not produce the data immediately without notifying us — unless the request legally prohibits you from telling us (a national security letter or similar order with a gag clause)
- Notify the CISO as soon as possible — if the request prohibits notification to us, notify us to the extent the law permits
- The request may have timelines attached — tell us the deadline in your notification
- We will seek legal advice and instruct you on how to respond
This is not about obstructing legitimate legal processes. It is about ensuring that we can exercise any legal rights we have (such as asserting legal professional privilege over some documents) before the data is produced, and about ensuring we are aware of regulatory interest in our data.
6.3 — Data minimisation and purpose limitation
You must process only the personal data we provide to you, for only the purposes we have authorised, and only for as long as necessary.
Data minimisation: Do not collect or retain personal data beyond what is needed for your processing purpose. If you discover that you hold personal data about our employees, customers, or others that was not provided intentionally (for example, personal data that appeared in a test file or was included in a broader data transfer by mistake), notify the CISO and we will determine whether it should be retained or deleted.
Purpose limitation: The personal data we share with you is provided for a specific processing purpose defined in your DPA. You may not use it for any other purpose — including internal analytics, marketing, model training, product improvement, or any commercial purpose — without our explicit written consent.
Automated decision-making: If your processing involves automated decision-making with legal or similarly significant effects on individuals (for example, automated scoring, automated hiring decisions, automated fraud detection that determines outcomes for individuals), this must be disclosed in your DPA and agreed with us before processing begins. UK GDPR imposes specific requirements on automated decision-making.
Section 7 — Practical guidance for common situations
Answers to the questions suppliers most commonly ask about data handling. If your situation is not covered here, contact the CISO.
SITUATION: I need to test software using realistic data. Can I use the
personal data in the production system?
ANSWER: No. Production personal data must not be used in test environments.
Use synthetic data that has the same structural characteristics as production
data but contains no real personal information. If synthetic data generation
is not practical for your testing, discuss with the CISO — there are
techniques for pseudonymising or anonymising production data for testing
purposes, but these must be agreed and documented before use.
SITUATION: A colleague at a different client of ours is working on a
similar problem. Can I share the technical approach I've learned from
working with you, without sharing specific data?
ANSWER: Depends. The technical approach (methodology, framework, solution
architecture in general terms) is probably not INTERNAL classified unless
it is specific to our implementation. However, you must not disclose:
any specific technical details of our infrastructure or security architecture;
any information about our compliance posture or ISMS; any information about
specific contracts we hold. If you're unsure whether a specific piece of
information is shareable, ask the CISO before sharing it. The default is:
when in doubt, do not share.
SITUATION: We have a junior employee who would benefit from working on our
engagement for learning purposes. They don't technically need access to the
personal data — they'll just be working alongside the senior colleague who does.
ANSWER: The fact that they are alongside someone with access does not mean
they are authorised. If there is any possibility they will see, access, or
incidentally encounter personal data (or CUI, or OFFICIAL information) in
the course of the learning exercise, they need to be formally authorised,
screened to the appropriate level, and included in the DPA authorised persons
list. Tell us you want to add them to the engagement and we will process it
through the onboarding steps. This is quick — a few days — and protects
both of us.
SITUATION: Our contract is ending but we think we'll have a follow-on
contract soon. Can we retain the personal data for now instead of deleting
it?
ANSWER: No. The data retention obligation under your DPA requires deletion
or return within 30 days of contract end. A speculative future contract does
not change this. If the follow-on contract is agreed, we will re-share the
data under the new contract with a new DPA (or a renewal of the existing DPA).
Retaining personal data beyond the required period without a legal basis is a
breach of the purpose limitation and storage limitation principles in UK GDPR.
SITUATION: We had a phishing incident on our side. We don't think any of
your data was accessed — the phishing email landed in a mailbox that doesn't
have access to your systems. Do we need to report it?
ANSWER: Yes, you should notify us. Even if you believe your data was not
affected, you cannot be certain at the time of the incident that the phishing
was not the beginning of a wider compromise. We would rather receive a
notification that turns out to be precautionary than miss a genuine incident
because it was self-assessed as low-risk. Our Category B notification (within
4 hours for Critical-tier, within 24 hours for Standard-tier) covers incidents
where impact on our data "cannot be ruled out." Notify us, tell us what
happened, and let us assess alongside you.
Section 8 — Contacts and further information
For all data handling questions, DPA requests, CUI classification
queries, incident reporting, and export control questions:
CISO (primary contact):
Name: [CISO name]
Email: [ciso@organisation.com]
Phone: [CISO direct line] (business hours)
Mobile: [CISO mobile] (Category A incidents — 24/7)
For personal data and UK GDPR specific questions:
DPO (if appointed) or CISO:
Name: [DPO name / CISO name]
Email: [dpo@organisation.com / ciso@organisation.com]
For CUI export control specific questions:
CISO (in the first instance — will engage export control counsel as needed)
ICO (for data subjects exercising rights against us directly):
ico.org.uk/make-a-complaint (data subjects should use this if they
cannot resolve their query with us directly)
NARA CUI Registry (for CUI category questions):
archives.gov/cui
For UK GDPR guidance:
ico.org.uk
Confluence page version and review
Evidence filing:
DPA records: EV-C → Risk Management → Supplier Assessments
→ [Supplier name] → DPA
CUI handling records: EV-C → Risk Management → Supplier Assessments
→ [Supplier name] → CUI Handling Confirmation
ITAR/EAR access records: EV-C → Risk Management → Supplier Assessments
→ [Supplier name] → Export Control Records
Retention:
DPAs: contract duration + 6 years
CUI handling confirmation records: 3 years from engagement end
Export control records: as required by DDTC/BIS guidance (minimum 5 years)
Review triggers (in addition to annual review):
Any new data category entering scope (new contract type)
ICO guidance change affecting our DPA standard provisions
New NIST 800-171 revision or CMMC programme update
ITAR/EAR regulatory change
Significant supplier data breach that reveals a handling gap
Review cycle: Annual — reviewed alongside Policy 04 (Information
Classification and Handling Policy)
Page owner: CISO
Questions: [ciso@organisation.com]
| Version | Date | Prepared by | Key changes |
|---|---|---|---|
| 1.0 | [DATE] | CISO | Initial publication |