SECRET and TOP SECRET Handling

Purpose

This page defines the operating standard for secret and top secret handling within the Security, Vetting and Technical Assurance Playbook. It is written for delivery teams, technical leads, security leads, commercial leads, suppliers and customer stakeholders who need a clear and evidence-based way to plan, build, assure and operate secure services.

The intent is to make security repeatable. Security must be visible in contracts, Statements of Work, architecture, backlog items, access decisions, technical controls, assurance evidence and live operations.

Operating Standard

The required operating standard is:

• security is built into the work from mobilisation, not added after delivery;

• access is granted only on the basis of identity, role, attributes, need, approval and evidence;

• data is classified, handled, stored, transmitted and disposed of according to its sensitivity;

• technical controls are mapped to risks, requirements and acceptance criteria;

• suppliers inherit the controls relevant to the work they perform;

• evidence is maintained continuously and is capable of supporting audit, accreditation and customer assurance;

• exceptions are time-bound, risk-owned and formally accepted.

Required Controls

Control	Implementation Standard	Evidence
C01	Classify information when created or received and mark it where required.	Policy, design record, approval, log extract, test result or review record.
C02	Apply OFFICIAL, SECRET and TOP SECRET handling in line with customer and HMG requirements.	Policy, design record, approval, log extract, test result or review record.
C03	Apply additional controls for OFFICIAL-SENSITIVE or other caveats where risk requires.	Policy, design record, approval, log extract, test result or review record.
C04	Map classification to storage, transmission, access, export, printing, retention and disposal controls.	Policy, design record, approval, log extract, test result or review record.
C05	Do not move information to unapproved tools, repositories or AI systems without approval.	Policy, design record, approval, log extract, test result or review record.

Delivery Lifecycle Requirements

Lifecycle point	Required security activity
Opportunity and qualification	Identify customer security constraints, likely classification, vetting needs, regulatory drivers, cyber risk profile, hosting restrictions and accreditation expectations.
Statement of Work	Define security scope, assumptions, responsibilities, acceptance criteria, evidence requirements, supplier obligations and change control triggers.
Mobilisation	Appoint security roles, complete onboarding, confirm tooling, create evidence library, open risk register and baseline access model.
Discovery	Identify assets, users, data, threats, dependencies, existing controls, constraints and assurance route.
Alpha or design	Perform threat modelling, architecture review, identity model design, data flow review and control mapping.
Build and test	Apply secure development practices, code review, automated security tests, configuration hardening and evidence capture.
Release	Verify quality gates, approvals, residual risk, monitoring, rollback, support and incident response readiness.
Live service	Monitor controls, review access, manage vulnerabilities, test recovery, report metrics and drive continuous improvement.
Closure or transition	Remove access, archive evidence, dispose of data, confirm supplier exit and record lessons learned.

Roles and Accountability

Role	Accountability
Security Lead	Owns the security approach, control mapping, assurance evidence and security risk advice.
Delivery Lead	Ensures security work is planned, tracked and integrated into delivery governance.
Technical Lead	Owns architecture, engineering controls, technical remediation and implementation evidence.
Commercial Lead	Ensures the contract, SoW and supplier terms contain required security obligations.
Data Owner	Confirms data classification, usage, retention and disposal requirements.
System Owner	Owns live operational risk, service acceptance and ongoing control effectiveness.
Supplier Lead	Ensures supplier controls, flow-down obligations and supplier evidence are complete.
Customer Security Authority	Provides customer-specific policy direction, approvals and risk acceptance where required.

Minimum Evidence Pack

Maintain evidence that proves the control is designed, implemented, reviewed and operating. The minimum evidence pack should include:

• security requirements and assumptions;

• risk assessment and risk treatment record;

• architecture and data flow diagrams;

• identity and access model;

• control mapping matrix;

• test and assurance evidence;

• access approval and review records;

• change and release approvals;

• incident, vulnerability and exception records;

• customer or authority approvals where required.

Metrics and Reporting

Use measurable indicators rather than subjective statements. Suitable metrics include:

• percentage of required controls implemented;

• number of overdue security actions;

• number of open high or critical vulnerabilities;

• access review completion rate;

• incident response time and recovery time;

• number of unapproved exceptions;

• supplier evidence completion rate;

• percentage of releases passing quality gates first time;

• age of residual risks awaiting acceptance.

Quality Gate

Before this area is treated as complete, confirm that:

• required controls are implemented or have approved exceptions;

• evidence is stored in the agreed location;

• owners are named;

• review cadence is scheduled;

• risks are within tolerance or formally accepted;

• supplier obligations are flowed down where applicable;

• customer-specific requirements have been checked;

• the position is ready for audit or customer assurance review.

Common Failure Modes

Common failures to avoid:

• assuming security clearance automatically grants access;

• granting access before screening, approval or need-to-know is confirmed;

• treating a policy document as evidence of actual control operation;

• leaving security requirements out of the SoW;

• failing to flow obligations to subcontractors;

• relying on manual evidence that cannot be reproduced;

• resolving technical issues without updating risk and assurance records;

• building in one environment and deploying into another without reassessing controls.

Checklist

• Requirement defined

• Owner appointed

• Risk assessed

• Controls mapped

• Evidence location confirmed

• Supplier impact checked

• Access model reviewed

• Data handling reviewed

• Quality gate defined

• Exception route confirmed

• Review cadence scheduled