FC-06 · Physical Protection and FC-07 · Media Protection — IT Staff Technical Procedures
SCM variant: isms-it-staff · isms-security. This content sits below the all-staff guidance in FC-06 and FC-07 and is not visible to isms-all-staff.
Document scope and architecture
This procedure covers the technical and operational implementation of physical protection controls and media protection controls for CUI-scope facilities and assets.
FC-06 Physical Protection implements NIST SP 800-171 controls 3.10.1–3.10.6 (six controls), four CMMC Level 1 practices (PE.L1-3.10.1, PE.L1-3.10.2, PE.L1-3.10.3, PE.L1-3.10.5), Cyber Essentials physical access requirements, and DEFSTAN Profile 0 §Physical and Profile 1 §Physical.
FC-07 Media Protection implements NIST SP 800-171 controls 3.8.1–3.8.9 (nine controls), one CMMC Level 1 practice (MP.L1-3.8.3), Cyber Essentials device and media requirements, and DEFSTAN Profile 1 §Physical and Profile 2 §Data Handling.
Procedures in this document:
FC-06: - Section 1: Facility zone model and access control architecture - Section 2: Access control system (ACS) configuration and management - Section 3: Card and credential lifecycle management - Section 4: Visitor and contractor administration - Section 5: CCTV management - Section 6: Physical security monitoring and evidence
FC-07: - Section 7: Media register management (EV-D22) - Section 8: Media sanitisation procedure by media type - Section 9: Destruction certificate process (EV-D25) - Section 10: Internal sanitisation log (EV-D26) - Section 11: Removable media policy and technical enforcement - Section 12: Evidence generation and maintenance
FC-06 · Physical Protection — IT Staff Technical Procedures
Section 1 — Facility zone model and access control architecture
1.1 Zone definitions and access control scope
The physical security model uses a three-zone structure aligned with the
network zone model (documented in FC-01 and AT-SC-BDY).
Physical zone boundaries and network zone boundaries are intentionally aligned —
a breach of a physical zone should not provide additional network access
beyond what the physical zone is designed to protect.
ZONE DEFINITIONS:
Zone 1 — Public area:
Scope: Reception, meeting rooms accessible to external visitors,
public-facing areas
Access: No ACS control — open to visitors with host escort
CUI: No CUI systems or printed CUI permitted in Zone 1
Network: Zone 5 (guest VLAN only) — no connection to Zones 2, 3, or 4
Controls: CCTV coverage at all entry/exit points; visitor sign-in register
at reception; staffed reception during business hours
Zone 2 — Controlled area:
Scope: General office space, staff workstations, meeting rooms
accessible only to employees and escorted visitors
Access: ACS-controlled — access card required at all entry points
CUI: CUI work may occur here; screens positioned to prevent
visibility from Zone 1 or by unauthorised Zone 2 visitors
Network: Zone 2 (internal general network)
Controls: ACS logging of all entry events; CCTV at primary entry/exit
points; clear desk policy enforced; visitors require escort
Zone 3 — Secure area:
Scope: Server room, network equipment room, secure storage,
CISO office (where sensitive documents are processed)
Access: ACS-controlled with PIN + card (two-factor physical access);
only named individuals on the Zone 3 access list
CUI: Primary CUI processing environment; servers and storage
containing CUI are physically located in Zone 3
Network: Zone 3 (CUI server VLAN) and Zone 4 (management VLAN)
Controls: ACS logging of all entry events; dedicated CCTV camera at
Zone 3 entry point; access list reviewed quarterly (EV-D23);
no visitors permitted without IT Manager written authorisation
CMMC LEVEL 1 MAPPING:
PE.L1-3.10.1: ACS on Zone 2 and Zone 3 entry points
PE.L1-3.10.2: CCTV and physical access devices (cards, PINs)
PE.L1-3.10.3: Visitor escort requirement throughout Zones 2 and 3
PE.L1-3.10.5: Alternative work site security requirements
DEFSTAN PROFILE MAPPING:
Profile 0: Zone 2 and Zone 3 physical controls (basic boundary protection)
Profile 1: Zone 3 server room controls; maintenance personnel supervision;
equipment accountability
ACS PLATFORM:
Platform: [deployed product — e.g. HID ProWatch / Lenel OnGuard /
Genetec Security Centre / Paxton Net2 / Brivo / specify]
Management URL: [internal console URL]
Management auth: PAM-mediated — IT Manager and Facilities Manager only
SIEM integration: ACS events forwarded to SIEM (see Section 5)
Section 2 — Access control system configuration and management
2.1 ACS hardware configuration
DOOR CONTROLLER CONFIGURATION:
Each ACS-controlled door has:
Reader: Card reader (Zone 2 doors); card + PIN keypad (Zone 3 doors)
Controller: Door controller managing the electronic lock
Lock type: Magnetic lock or electric strike — fail-secure (locks on power loss)
EXCEPTION: fire exit doors must be fail-safe (unlocks on power loss)
to comply with fire safety regulations
Fire exit ACS doors: fail-safe + battery backup + manual override
Fail-secure vs fail-safe configuration:
All Zone 2 and Zone 3 entry doors: fail-secure (power loss = door locked)
Fire exit doors (any zone): fail-safe (power loss = door unlocks for evacuation)
Document each door mode in the ACS site plan maintained in EV-D23
CONTROLLER NETWORK CONFIGURATION:
ACS controllers: on dedicated management VLAN (Zone 4)
Not on general office network (Zone 2)
Management PC: IT Operations workstation in Zone 3 or dedicated ACS workstation
Network segmentation between ACS and CUI systems:
ACS controllers have no route to CUI servers (Zone 3 server VLAN)
ACS management software has no direct access to domain controllers
ACS events forwarded to SIEM via syslog from ACS management server:
Source: ACS management server → syslog → [SIEM-IP]:514
ANTI-PASSBACK CONFIGURATION:
Anti-passback prevents a card being used to enter a zone if it has
not also been used to exit (prevents card sharing/tailgating detection)
Enable: ACS software → Global settings → Anti-passback: Enabled
Mode: Hard anti-passback (reject entry if anti-passback violation)
OR Soft anti-passback (allow entry but generate alert)
Recommendation: Soft anti-passback for Zone 2 (fewer false alarms from
propped doors or fire evacuation); Hard anti-passback for Zone 3
Anti-passback forgiveness: ACS auto-reset every 24 hours (midnight)
Manual reset: ACS console → Cardholders → [cardholder] → Reset anti-passback
DOOR TIMING CONFIGURATION:
Door hold-open time (time lock stays unlocked after valid card read):
Zone 2 standard doors: 5 seconds
Zone 2 wide doors (equipment access): 10 seconds
Zone 3 doors: 4 seconds (reduced to limit tailgating window)
Adjustable: ACS software → Doors → [door] → Door timing → Unlock duration
Door open too long alert:
Zone 2: alert after 30 seconds held open
Zone 3: alert after 20 seconds held open
Alert: SIEM event (via syslog) + ACS console notification
Response: security team verifies door status via CCTV; contacts area occupant
DURESS CODE CONFIGURATION (if supported by deployed ACS platform):
A duress PIN variant (e.g. standard PIN + 1 on the last digit) silently alerts
while appearing to grant access normally
Configure in ACS software → Cardholders → PIN settings → Duress code: Enabled
Duress alert: SIEM High-severity event + silent alarm to Facilities Manager
and CISO mobile
Test duress code: quarterly (confirm alert fires; confirm door opens normally)
2.2 Access group configuration
Access groups in ACS define which cardholders can access which doors
and at what times. Group-based access is mandatory — individual door
assignments per cardholder create unmanageable configurations.
STANDARD ACCESS GROUPS:
Group: AG-AllStaff-Zone2
Doors: All Zone 2 entry/exit points (general office access)
Schedule: Business hours (07:00–20:00, Monday–Friday)
+ 30-minute grace outside hours for late working
Members: All staff (auto-assigned on provisioning via HR trigger)
Group: AG-AllStaff-Zone2-ExtendedHours
Doors: All Zone 2 entry/exit points
Schedule: 24/7 (for staff with business need for weekend/overnight access)
Members: Named individuals approved by IT Manager + CISO
Review: Quarterly — confirm continued need; remove if role has changed
Group: AG-ITOps-Zone3
Doors: Server room entry (Zone 3) — card + PIN
Schedule: Business hours + on-call emergency access (24/7 with PIN)
Members: IT Operations team only (individually named)
Review: Quarterly as part of EV-D01 privileged account review
(Zone 3 physical access = privileged — reviewed alongside IT system access)
Group: AG-Facilities-Zone3
Doors: Server room (Zone 3) + building plant rooms
Schedule: Business hours only; emergency access via ACS override with IT Manager approval
Members: Facilities Manager (named individual)
Review: Quarterly
Group: AG-SecurityTeam-Zone3
Doors: All Zone 3 doors; all Zone 2 doors
Schedule: 24/7
Members: CISO (named individual)
Review: Annual
Group: AG-Visitor-EscortRequired
Doors: Zone 2 doors (not Zone 3)
Schedule: Business hours only (08:00–18:00, Monday–Friday)
Members: Visitor cards (temporary — see Section 4)
Access restriction: Visitor cards in this group CANNOT open doors without
a staff escort present — enforced via ACS escort mode
configuration where supported by platform
Group: AG-Contractor-Supervised
Doors: Specific doors relevant to the contractor's work area
Schedule: Pre-defined maintenance window only
Members: Named contractor individuals (temporary cards)
Created: per contract/maintenance event; deleted after completion
ZONE 3 ACCESS LIST (maintained as annex to EV-D23):
This is a separate document maintained by the Facilities Manager
and reviewed by the CISO quarterly
Fields per entry:
Name | Role | AG-ITOps-Zone3 member | Access card number |
Date added | Date last reviewed | Approved by | Notes
Current members (maintained separately — not documented in public procedures
for operational security):
[IT Operations team names — documented in the access list annex]
Any individual not on this list found in Zone 3 without an IT Operations escort:
Treat as a security incident; report to CISO immediately
2.3 Schedule and time zone configuration
BUSINESS HOURS DEFINITION:
Standard business hours: 07:00–20:00 Monday–Friday
Adjust in ACS software: Schedules → Standard Business Hours → Edit
Public holidays: configure as exceptions in ACS schedule calendar
(Annual task: update holiday calendar in January for the coming year)
AFTER-HOURS ACCESS:
Zone 2 after-hours: only AG-AllStaff-Zone2-ExtendedHours members
Zone 3 after-hours: only AG-ITOps-Zone3 members (with valid reason — logged)
After-hours Zone 3 access alert:
SIEM alert rule: Zone 3 access event between 20:00 and 07:00 on weekday
OR any Zone 3 access event on weekend
Severity: Medium (expected for on-call IT; unexpected for others)
Alert to: CISO + IT Manager mobile push notification
Response: CISO confirms legitimate purpose or escalates as incident
WEEKEND AND HOLIDAY ACCESS:
Zone 2: only AG-AllStaff-Zone2-ExtendedHours (pre-approved individuals)
Zone 3: only AG-ITOps-Zone3 and AG-SecurityTeam-Zone3
SIEM: alert on any Zone 2 or Zone 3 access event on UK public holidays
Planned weekend maintenance:
IT Operations notifies CISO in advance
No special process required if person is already in Zone 3 access group
Maintenance activity logged in EV-D21 (RFC) — not in ACS
Section 3 — Card and credential lifecycle management
3.1 Card provisioning (joiners)
TRIGGER: HR notifies IT Operations of new starter via ITSM onboarding ticket
(Same trigger as the JML process in FC-03 IT Staff Technical Procedures)
PROVISIONING CHECKLIST — complete before new starter's first day:
□ STEP 1: Obtain card hardware
Collect an unprovisioned access card from the secure card stock
Card stock: locked in Facilities Manager's office; quantity tracked in
a separate card inventory register (maintained by Facilities)
Record: card number from the printed number on the card face/back
□ STEP 2: Programme card in ACS
ACS console → Cardholders → Add new cardholder
Fields to complete:
First name, Last name: from HR onboarding ticket
Employee ID: from HR system (must match Entra ID employee ID attribute)
Department: from HR onboarding ticket
Status: Active
Card number: [number from card hardware]
Card format: [site-specific format — e.g. HID 26-bit Wiegand / MIFARE Classic]
Facility code: [site facility code — document in EV-D23 annex]
PIN: [generate 6-digit PIN using IT Operations PIN generation procedure]
Note: do not use obvious PINs (birthdate, 123456, 000000, etc.)
Deliver PIN separately from card — email PIN to personal email
or notify verbally in person; never write on the card envelope
Access groups:
Standard staff: assign AG-AllStaff-Zone2 only
IT Operations role: additionally assign AG-ITOps-Zone3 (IT Manager approval required)
Expiry date:
Permanent staff: no expiry (access managed by group schedule)
Fixed-term contractors: set card expiry = contract end date
Temporary workers: set card expiry = engagement end date
□ STEP 3: Test card operation
Before issuing to the new starter, test the card on a Zone 2 reader
Confirm: door unlocks; access log shows the cardholder name correctly
If Zone 3 is assigned: test on Zone 3 reader with PIN
□ STEP 4: Issue card and brief new starter
Issue card in person (not by mail or left on a desk)
Verbal briefing:
"This card gets you into the office. Keep it on you at all times.
Report it lost immediately if you cannot find it.
Do not share it or let anyone use it after you — if you see someone
tailgating through a door you opened, ask them to badge in themselves."
Brief must include: tailgating prohibition; reporting obligations
□ STEP 5: Record issuance
Update the ACS cardholder record: Issue date = [today]; Issued by = [your name]
Record in EV-D03 JML log (physical access section):
Card number | Cardholder name | Issue date | Access groups assigned | Issued by
ZONE 3 CARD PROVISIONING (additional steps):
Zone 3 access requires IT Manager approval (in addition to standard provisioning)
Approval: ITSM ticket — IT Manager approves in ticket before ACS change is made
Group assignment: AG-ITOps-Zone3 added to cardholder record after approval
Zone 3 access list: add entry to EV-D23 Zone 3 access list annex
PIN configuration: Zone 3 PIN is separate from Zone 2 PIN (different PIN for Zone 3 pad)
Some platforms support role-specific PINs — configure if available
3.2 Card suspension and deactivation (movers and leavers)
LEAVER PROCEDURE — SAME-DAY DEACTIVATION:
Target: card deactivated within 1 hour of final working day notification from HR
(Aligned with FC-03 JML leaver procedure — physical access deactivation
is Step 2 in the nine-step leaver checklist, EV-D04)
ACS deactivation (Facilities Manager or IT Operations):
ACS console → Cardholders → [search by name or employee ID]
Status: change from Active to Inactive
Do NOT delete the cardholder record — retain for audit trail
Note: deactivating (not deleting) preserves the access history in ACS logs
This is required for: incident investigations, DEFSTAN assessments,
and the post-departure SIEM review (FC-03 leaver procedure)
Card return:
Physical card returned to IT Operations at exit interview (HR manages)
If card cannot be returned (lost before final day, remote worker, etc.):
Mark in ACS: Card status = Lost + deactivated
Do not reuse the card number — retire it
Record: "Card not returned — deactivated [date]" in EV-D03
Post-departure access log check:
Within 24 hours of deactivation: verify no access events in ACS log
for the deactivated card after the deactivation time
If any events appear: investigate immediately — possible cloned card
ACS query:
Reports → Access history → Filter by: Cardholder = [departed name]
Date: from deactivation time to now
Expected: zero events after deactivation timestamp
MOVER PROCEDURE — ROLE CHANGE:
When an employee changes role and no longer needs Zone 3 access:
ACS console → Cardholders → [cardholder] → Access groups
Remove: AG-ITOps-Zone3 (or other group no longer required)
Add: any new group required by new role
Update EV-D23 Zone 3 access list: remove the individual's entry
Record change in EV-D03 JML log (physical access section)
TEMPORARY SUSPENSION (leave of absence, secondment, extended sick leave):
If >4 weeks absence: suspend card (not delete)
ACS: Cardholder status = Suspended (or equivalent term in deployed platform)
Suspended card: cannot be used for access; audit history preserved
Reinstatement: when employee returns — restore to Active via HR notification
Record: suspension and reinstatement dates in ACS cardholder notes field
3.3 Quarterly access review procedure
Frequency: Quarterly — aligned with EV-D01 privileged account review (FC-03)
Producer: Facilities Manager (ACS export) + IT Manager (cross-reference)
Evidence: EV-D23 quarterly access review record
STEP 1 — Export current ACS cardholder list (Facilities Manager):
ACS console → Reports → Cardholders → Export all Active cardholders
Export fields: Name, Employee ID, Department, Access Groups, Card Number,
Card Status, Card Issue Date, Last Access Date
Format: CSV
Save as: ACS-Export-[YYYY-QQ].csv
STEP 2 — Export HR active employee list (HR Manager provides):
HR system export: all currently employed staff + active contractors
Fields: Name, Employee ID, Department, Employment Status, Contract End Date
Format: CSV
Save as: HR-Active-[YYYY-QQ].csv
STEP 3 — Cross-reference (IT Manager):
Compare ACS export against HR export:
PowerShell comparison:
$acs = Import-Csv "ACS-Export-[YYYY-QQ].csv"
$hr = Import-Csv "HR-Active-[YYYY-QQ].csv"
# Find ACS cards with no HR record (departed employees with active cards)
$orphaned = $acs | Where-Object {
$_.Status -eq "Active" -and
$hr.EmployeeID -notcontains $_.EmployeeID
}
$orphaned | Format-Table Name, EmployeeID, LastAccessDate
# Find ACS cards with expired contract dates still active
$expired_contractors = $acs | Where-Object {
$_.CardExpiry -ne "" -and
[datetime]$_.CardExpiry -lt (Get-Date) -and
$_.Status -eq "Active"
}
Any orphaned active card (ACS active, no HR record):
Immediate action: deactivate the card; investigate why leaver process missed it
Record as finding in EV-D23 review; create corrective action in EV-A03
STEP 4 — Zone 3 access list verification (IT Manager + CISO):
Review every person on the Zone 3 access list (EV-D23 annex)
For each person:
Is their role still appropriate for Zone 3 access?
Have they had a Zone 3 access event in the past 90 days?
If no access events: challenge whether access is still needed
Have they completed required training (security awareness — EV-B05)?
Remove any individual whose role no longer justifies Zone 3 access
Document rationale for any individual retained without recent access events
STEP 5 — After-hours and extended hours group review:
Export members of AG-AllStaff-Zone2-ExtendedHours and AG-ITOps-Zone3
For each member: confirm continued business need for 24/7 access
Remove any members without documented current need
STEP 6 — Last access date check:
ACS: identify any active cards with LastAccessDate > 90 days ago
(A card that has not been used in 90 days may belong to a long-term
absence or a departed employee whose card was not collected)
For each: contact HR to confirm employment status
If departed: deactivate immediately
If on approved long-term absence: suspend (see Section 3.2)
If active and simply not using card recently: confirm with manager
STEP 7 — Document and file EV-D23:
EV-D23 Quarterly Physical Access Review — [YYYY-QQ]
Review date: [date]
Reviewed by: Facilities Manager [name] + IT Manager [name]
CISO review: [name] (for Zone 3 section)
ACS export date: [date] — total active cardholders: [N]
HR export date: [date] — total active employees/contractors: [N]
Cross-reference findings:
Orphaned active cards found: [N]
Actions taken: [list — deactivated; investigated]
Expired contractor cards still active: [N]
Actions taken: [list]
Cards not used in >90 days: [N]
Actions taken: [list — confirmed active; suspended pending HR check; deactivated]
Zone 3 access list:
Current members: [N]
Members removed this quarter: [N names]
Reason for removal: [list]
Members retained without recent access event: [N — justified as: on-call role /
annual maintenance / etc.]
After-hours group review:
AG-Zone2-ExtendedHours: [N] members — [N] removed
AG-ITOps-Zone3: [N] members — [N] removed
Overall assessment: Compliant / Issues found (see above)
Facilities Manager sign-off: _____________ Date: _________
IT Manager sign-off: __________________ Date: _________
CISO sign-off (Zone 3 section): ________ Date: _________
File at: EV-D → Physical Security → Access Logs → [YYYY-QQ]
Section 4 — Visitor and contractor administration
4.1 Visitor log and sign-in procedure
VISITOR CATEGORIES:
Category A — Business visitor (scheduled):
Examples: supplier meeting, client presentation, job interview
Host: named employee who booked the meeting
Pre-notification: host emails Facilities by [N] business days in advance
Areas permitted: Zone 1 (meeting rooms), Zone 2 escorted only
Zone 3: not permitted under any circumstances without IT Manager written approval
Category B — Maintenance contractor (scheduled):
Examples: facilities maintenance, IT equipment supplier, fire system test
Pre-notification: minimum 24-hour notice via ITSM ticket (not email to Facilities)
ITSM ticket: contractor name, organisation, purpose,
area to be accessed, expected duration,
named IT Operations escort (for any Zone 2/3 work)
Areas permitted: depends on work — documented in ITSM ticket
Zone 3: requires IT Operations escort at all times
Category C — Emergency visitor (unscheduled):
Examples: emergency facilities contractor, unplanned equipment delivery
Reception staff: require proof of ID + call to confirm with the relevant
department before allowing past reception
Do not allow unescheduled visitors past Zone 1 without host confirmation
Category D — DEFSTAN contracting authority representative:
Examples: contracting authority audit, site inspection, cleared visitor
Pre-notification: minimum 5 business days; CISO notified immediately
Identity verification: verify authority credentials + confirm against expected
visitor list provided by the contracting authority
Areas: as required for the assessment; CISO accompanies throughout
VISITOR SIGN-IN PROCEDURE (all Categories):
Location: Reception desk (Zone 1)
Managed by: Reception staff or Facilities Manager
Required information at sign-in:
□ Visitor full name: [printed clearly in register]
□ Organisation/company: [if external]
□ Purpose of visit: [brief description — e.g. "Meeting with [host name]"]
□ Host/escort: [named employee responsible for the visitor]
□ Identity verified: [Yes — document type shown, e.g. "Passport" or "Driver's licence"]
[No — document why verification was not possible]
□ Visitor badge number: [badge number issued from badge rack]
□ Time in: [HH:MM]
□ Time out: [HH:MM — completed when visitor leaves]
□ Visitor signature (or initials): [confirms agreement to site rules]
□ Host signature (or initials): [confirms host has collected visitor]
Visitor badge rules:
All visitors issued a physical visitor badge to wear visibly throughout visit
Badge must be returned at sign-out
Missing badge: report to Facilities Manager; investigate if visitor left site
Badge rack: kept at reception; numbered badges 001–[N]
Badge stock: Facilities Manager orders replacements when stock below 10
Site rules briefing (host's responsibility at visitor reception):
Host must verbally brief each visitor:
"Mobile phones and cameras are [permitted in meeting rooms only /
not permitted beyond reception — specify per site policy]"
"Please stay with me at all times beyond the meeting room"
"Please do not access any computers or equipment in the office"
"If you need to leave the building, please let me know so I can sign you out"
VISITOR SIGN-OUT PROCEDURE:
Host returns visitor to reception
Reception completes: Time out field + confirms badge returned
Any visitor who appears to leave without signing out:
Reception staff contact the host immediately
Check CCTV to confirm exit time if possible
Incomplete sign-out records are a compliance gap — record what is known
and note "visitor departed without completing sign-out procedure"
VISITOR LOG STORAGE:
Physical register: locked in reception desk at end of business day
Retention: 12 months (then shred — visitor data per GDPR retention schedule)
For DEFSTAN assessments: retain all visitor records for the duration of
the contract + 1 year (may extend retention obligation — confirm with CISO)
Digital visitor log (if using visitor management software):
Platform: [e.g. iLobby / Envoy / WhosOnLocation / specify]
Data retention: 12 months (GDPR minimum for security purposes)
SIEM integration: visitor log system events forwarded to SIEM (optional)
Privacy notice: GDPR-compliant notice displayed at sign-in kiosks
4.2 Contractor management procedure
IT and facilities contractors working on CUI-scope infrastructure require
additional controls beyond the standard visitor procedure.
CONTRACTOR ITSM TICKET REQUIREMENTS:
Submit minimum 24 hours before contractor arrival:
Ticket fields:
Contractor company: [company name]
Individual contractor name(s): [full names of all individuals attending]
Purpose: [specific work to be performed — e.g. "Replace UPS battery in server room"]
Location: [specific zone and room — e.g. "Zone 3 — server room"]
Scheduled date and time: [YYYY-MM-DD HH:MM to HH:MM]
IT Operations escort: [named IT Operations engineer who will escort]
Screening status: [BPSS screened / Not screened]
If not BPSS screened: IT Operations escort must maintain visual
supervision at all times (cannot leave the contractor alone)
If BPSS screened: confirmation record reference from EV-B08 (AT-PS)
DEFSTAN REQUIREMENT — SUPERVISION OF NON-CLEARED PERSONNEL:
For contractors who do not hold BPSS screening or higher:
Must be supervised throughout by a named, cleared IT Operations engineer
Supervision means: direct line of sight at all times; no access to
CUI systems or storage; cannot be left alone in Zone 3
Before contractor accesses Zone 3:
IT Operations engineer confirms: all CUI screens locked
CUI removable media: removed from the server room if feasible
If not feasible: specific media physically secured (locked rack/drawer)
During contractor work in Zone 3:
IT Operations engineer present and observing throughout
Note: "observing" — not just in the same room on a separate task
CONTRACTOR RECORD — EV-D24:
For each contractor visit, create an EV-D24 maintenance/contractor record:
EV-D24 Contractor Visit Record — [REF]
Contractor company: [name]
Contractor individual(s): [full names]
Organisation contact: [manager/coordinator name at contractor company]
Purpose of visit: [specific work performed]
Zone(s) accessed: [Zone 2 / Zone 3 — specify rooms]
Screening level: [BPSS confirmed (ref: EV-B08-[ref]) / Not screened]
Supervised: Yes / No (Not screened = must be Yes)
IT Operations escort: [named engineer]
Date: [YYYY-MM-DD]
Time in: [HH:MM]
Time out: [HH:MM]
CUI protection actions taken before contractor Zone 3 access:
□ CUI screens locked / powered off
□ CUI portable media removed / secured
□ CUI documentation removed / secured
□ CUI not accessible on any visible display
Work performed: [description]
Systems affected: [list affected systems, if any — cross-reference EV-D21 RFC if applicable]
Issues during visit: [any issues; "None" if clean visit]
State of Zone 3 on departure: [Normal; no changes made except [specify] /
Issues found: [describe]]
IT Operations escort sign-off: _____________ Date: _________
CISO aware (if Zone 3 entry by non-cleared contractor): Yes / N/A
File at: EV-D → Physical Security → Contractor Records → [YYYY]
Section 5 — CCTV management
5.1 CCTV system configuration
CAMERA COVERAGE REQUIREMENTS:
All Zone 1 / Zone 2 entry and exit doors: minimum 1 camera per door
camera must capture face-on view
of person entering/exiting
Zone 3 entry: minimum 1 camera; face-on + full approach corridor
Internal Zone 1 (reception): 1 camera covering the reception desk area
Camera specifications:
Minimum resolution: 1080p (Full HD)
Field of view: sufficient to identify individuals at the door
Night vision: IR illumination or low-light capable for 24/7 coverage
Frame rate: minimum 15fps (25fps preferred for movement clarity)
Camera positions NOT required (and typically avoided for GDPR):
Internal workstation areas (Zone 2 office space — excessive surveillance)
Toilets, prayer rooms, or other private spaces
Areas where no security benefit exists
RECORDING AND RETENTION:
Continuous recording: 24/7 on all cameras (not motion-triggered)
Retention period: 31 days (minimum — aligned with ICO guidance for
security purposes with DPO sign-off)
For DEFSTAN contracts: the contracting authority may request footage
Review footage for the duration of any active DEFSTAN assessment period
Retain footage from all assessment dates until the assessment is concluded
and the contracting authority has confirmed no further retention is needed
GDPR note: CCTV is personal data processing
Privacy notice: displayed at building entry points
DPO registered: CCTV system registered with ICO if required
Subject access requests: procedure documented with DPO;
requests fulfilled within 30 days
Processor agreement: CCTV storage vendor has a signed GDPR processor agreement
DVR/NVR SYSTEM SECURITY:
DVR/NVR access: password changed from default (see FC-02 procedure)
Remote access to DVR/NVR: from management VLAN (Zone 4) only
DVR/NVR on corporate network: yes — but on dedicated security camera VLAN
(not Zone 2 or Zone 3 — prevents camera network
from being used as lateral movement vector)
DVR/NVR credentials: stored in PAM vault
Firmware: updated on the same schedule as network device firmware (Section 5.5 of FC-05)
Storage capacity verification (monthly):
NVR console → Storage → Available space
Expected: at least 35 days of storage available (supports 31-day retention
with buffer for high-activity days or increased bitrate events)
If less than 35 days: either increase storage or reduce retention duration
with CISO approval
5.2 Monthly CCTV health check procedure (generates EV-D29)
Frequency: Monthly (first working day of each month)
Producer: Facilities Manager
Duration: approximately 30 minutes
STEP 1 — Image quality verification:
Review live feed from each camera
For each camera confirm:
□ Image is clear and not obstructed (no lens fouling, spiderwebs, sun glare)
□ Full expected field of view is visible
□ Night vision is functioning (check footage from previous night if possible)
□ Timestamp is correct (if camera shows timestamp — verify against actual time)
□ No physical damage to camera housing
Document any image quality issues: camera name/number + issue description
STEP 2 — Recording confirmation:
DVR/NVR console → Recording status: confirm all cameras show recording
Confirm: recording is continuous, not motion-triggered only
Check: no storage full events in the past 30 days (would cause recording to stop)
Confirm: oldest recording available is at least 31 days old
(If oldest is only 7–14 days: storage may be recycling too quickly — investigate)
STEP 3 — Playback test (quarterly — in addition to monthly):
Select one camera
Retrieve a 5-minute clip from exactly 31 days ago
Verify: clip plays correctly; image quality is sufficient to identify individuals
This confirms: recordings are genuinely being retained (not just showing as retained)
Note: do not just verify that footage exists — play it back and confirm
the content makes sense (correct camera, correct time period, viewable quality)
STEP 4 — Access review (quarterly — in addition to monthly):
DVR/NVR: user account list
Who has access to view CCTV footage?
Acceptable: Facilities Manager, CISO, IT Manager (specific named individuals)
Remove: any accounts no longer required; any accounts for departed staff
EV-D29 Monthly CCTV and Facility Monitoring Check — [YYYY-MM]
Check date: [date]
Performed by: [Facilities Manager name]
Camera inventory: [N] cameras installed
Cameras checked: [N]
Per-camera status:
[Camera name/number] — [Zone] — [Status: OK / Issue: describe] — [Notes]
[Camera name/number] — [Zone] — [Status: OK / Issue: describe] — [Notes]
[continue for all cameras]
Recording system:
Recording status: All cameras recording / [N] cameras not recording: [describe]
Storage available: [N] days of footage
Oldest footage available: [date] ([N] days ago — target: ≥31 days)
Recording gaps in past 30 days: None / [describe]
Playback test (quarterly — tick if performed this month):
□ Playback test performed: [camera tested] — [date/time of clip retrieved] — [Result: OK/Fail]
DVR/NVR access review (quarterly):
□ Access review performed: [N] user accounts — [N] removed — Compliant
Corrective actions required:
[List any cameras with issues and the planned corrective action]
Or: "No corrective actions required"
Facilities Manager sign-off: _____________ Date: _________
File at: EV-D → Physical Security → CCTV Records → [YYYY-MM]
Section 6 — Physical security monitoring and evidence
6.1 SIEM integration for physical security events
ACS events forwarded to SIEM via syslog:
Protocol: syslog TCP to [SIEM-IP]:514
Format: [vendor syslog format — CEF/JSON/RFC5424 — specify]
Events to forward (minimum):
All successful Zone 3 access events (every entry)
All failed access attempts (invalid card, invalid PIN, anti-passback violation)
All after-hours Zone 2 access events (outside business hours schedule)
All door held-open-too-long events
All duress code activations
All ACS configuration changes (administrative events)
SIEM ALERT RULES FOR PHYSICAL SECURITY:
Rule: Zone 3 access outside business hours
Trigger: ACS event — Zone 3 door — access granted — timestamp outside 07:00–20:00
on weekday, OR any time on weekend/holiday
Severity: Medium
Alert: push notification to CISO and IT Manager mobile
Response: CISO confirms legitimate (IT Operations maintenance) or treats as incident
Rule: Failed Zone 3 access attempts
Trigger: ACS event — Zone 3 door — access denied — [N] attempts within 15 minutes
Severity: High (3+ attempts in 15 minutes)
Alert: CISO notification; review CCTV immediately
Rule: Door held open — Zone 3
Trigger: ACS event — Zone 3 door — held open >20 seconds
Severity: Medium
Alert: Facilities Manager; security analyst reviews CCTV
Rule: ACS cardholder record modified outside business hours
Trigger: ACS administrative log — cardholder record added, modified, or deleted
between 20:00 and 07:00
Severity: High (unexpected ACS changes outside business hours)
Alert: CISO immediately
Response: verify change was authorised; if not, investigate as potential insider threat
Rule: Visitor badge not returned (detected via long sign-out gap)
Not directly from ACS — from physical visitor log; manual check process
Automated version: if visitor management software is in use,
alert when visitor has been signed in for >2 hours past expected end time
MONTHLY SIEM REVIEW FOR PHYSICAL SECURITY (within EV-F01):
Security Analyst includes physical security events in monthly SIEM log review:
Zone 3 after-hours access events this month: [N] — all legitimate? [Y/N]
Failed Zone 3 access attempts: [N] — investigated? [Y/N]
ACS configuration changes: [N] — all authorised? [Y/N]
Any unexplained patterns: [describe or "None"]
These are a subsection of EV-F01 — not a separate evidence item
6.2 Physical security evidence schedule
Evidence production calendar:
DAILY:
[ ] Visitor log: ensure all visitors signed out (end of business day check)
[ ] Zone 3 after-hours SIEM alert queue: review any overnight Zone 3 events
[ ] Any ACS card access failures: review for patterns
WEEKLY:
[ ] ACS event log: spot-check 1 week of Zone 3 events; confirm all expected
[ ] CCTV storage: confirm adequate recording space remains
MONTHLY:
[ ] EV-D29: CCTV health check (by 5th of month)
[ ] Physical security section of EV-F01: SIEM event summary
[ ] Visitor log: archive previous month's pages; confirm sign-outs complete
QUARTERLY:
[ ] EV-D23: full access review (ACS export vs HR export; Zone 3 list review)
[ ] EV-D29: quarterly playback test and DVR access review
[ ] CCTV coverage review: walk the facility; confirm no new obstructions
[ ] ACS firmware: check for updates (same cycle as network device firmware)
ANNUALLY:
[ ] Physical security risk assessment: review zone model; any new access risks?
[ ] ACS: review all access group definitions; remove unused groups
[ ] Site plan update: confirm ACS site plan in EV-D23 annex reflects
current door layout and camera positions
[ ] Visitor log: confirm GDPR retention periods applied (shred records >12 months)
PER EVENT:
[ ] New employee: card provisioned before first day; EV-D03 updated
[ ] Employee departure: card deactivated within 1 hour; EV-D03 updated;
EV-D04 physical access deactivation section signed
[ ] Contractor visit: EV-D24 created; ITSM ticket referenced
[ ] DEFSTAN authority inspection: EV-D24 created; CISO accompanies;
access log retained beyond standard period
FC-07 · Media Protection — IT Staff Technical Procedures
Section 7 — Media register management (EV-D22 physical media section)
7.1 What the media register must capture
EV-D22 is the asset register for all IT assets. For media protection purposes,
the physical media section within EV-D22 tracks every physical device capable
of storing CUI data.
SCOPE — what must be registered:
□ All workstations and laptops with internal storage (HDD or SSD)
□ All servers with internal storage
□ All network-attached storage (NAS) devices
□ All external hard drives in organisational use
□ All USB drives issued to staff for work purposes
□ All backup tapes (if tape backup is in use)
□ All SD cards issued for work purposes (cameras, embedded systems)
□ All optical discs (CDs, DVDs) containing CUI (if any)
□ All phones and tablets enrolled in MDM
□ Decommissioned hardware awaiting disposal (separate section)
OUT OF SCOPE (not registered in EV-D22 but controlled by policy):
Personal devices owned by staff (not issued by organisation)
— these are controlled by MDM enrolment policy, not media register
Consumer USB drives brought to site by visitors — prohibited by policy
FIELDS PER MEDIA REGISTER ENTRY:
Field Content
──────────────────────────────────────────────────────────────────────────────────
Asset ID ORG-[ASSET TYPE]-[SEQUENCE] (e.g. ORG-LT-0042)
Asset type Laptop / Desktop / Server / NAS / ExtHDD / USB / Tape /
Phone / Tablet / Other (specify)
Manufacturer [Brand name]
Model [Model number]
Serial number [Full serial number — from device label or BIOS/UEFI]
Asset tag [Physical label affixed to device — if tagged]
Storage type HDD / SSD / eMMC / NAND flash / Tape / Optical / Other
Storage capacity [e.g. 512GB / 2TB / etc.]
Encryption Full Disk Encryption: Yes / No
Encryption method: BitLocker AES-256 / FileVault 2 /
LUKS AES-256 / VeraCrypt / Hardware (self-encrypting) / None
Encryption key stored: PAM vault / TPM (BitLocker) /
MDM escrow / [specify]
CUI scope Yes / No (does this device process or store CUI?)
Classification OFFICIAL / OFFICIAL-SENSITIVE / CUI / Unclassified
CUI marking applied Yes / No / Not applicable (digital-only marking)
Assigned to Named individual (user) OR "IT Operations pool" OR
"Server — [function]"
Physical location Zone 2 — General office / Zone 3 — Server room /
Zone 3 — Secure storage / Remote — [named user's home]
Current status In service / In storage / Awaiting sanitisation /
Awaiting disposal / Disposed / Lost
Date acquired [YYYY-MM-DD]
Vendor support end (OS) [Date OS reaches EOL — cross-ref AT-SI/FC-05]
Vendor support end (Fw) [Date device firmware no longer supported — if applicable]
Last verified [Date IT Operations last physically confirmed this asset]
Disposal date [YYYY-MM-DD — populated when device is disposed of]
Disposal method Vendor destruction / Internal sanitisation + shred /
Returned to supplier / Donated (only if sanitised)
Destruction cert ref EV-D25-[ref] — populated when destruction certificate received
Sanitisation log ref EV-D26-[ref] — populated when internal sanitisation is completed
Notes Any additional context
──────────────────────────────────────────────────────────────────────────────────
7.2 Media register maintenance
ADDITIONS TO REGISTER:
New device arrives:
IT Operations completes EV-D22 entry before the device is issued to a user
Serial number: recorded from device label BEFORE imaging or configuration
(Serial number can be harder to find after software is installed on some devices)
Physical verification: confirm serial number on device label matches what is
recorded — a transposition error in the serial number makes the destruction
certificate unmatchable later
UPDATES TO REGISTER:
Status changes that must update EV-D22 immediately:
Device issued to a new user: update "Assigned to" field
Device returned from user: update to "IT Operations pool" or "Awaiting sanitisation"
Device reported lost: update status to "Lost"; note date reported
Device sent for repair: update status; note repair vendor
Device returned from repair: update status to "In service"
QUARTERLY PHYSICAL RECONCILIATION:
Process: physically locate and verify every asset in EV-D22
Duration: approximately half a day for environments with <200 devices
Who: IT Operations (2 engineers — one reads from register; one locates device)
Method:
For each entry in EV-D22:
Physically locate the device in its documented location
Confirm: serial number on device matches EV-D22 entry
Update: "Last verified" date to today's date
Devices that cannot be located:
If "In service" status: contact assigned user to confirm location
If user cannot produce device: treat as lost; report to CISO;
begin lost device procedure (AT-IR)
If "In storage" status: escalate to IT Manager; may indicate
unauthorised removal from secure storage
Devices found but not in register:
Treat as unregistered asset — record immediately
Investigate: how did this device enter the environment without being registered?
(Common source: personal device brought to work and left; device from a
previous supplier relationship; shadow IT)
CISO notification: unregistered device in CUI-scope area = potential incident
DECOMMISSIONED DEVICE SECTION:
When a device is decommissioned (end of life, broken, or replaced):
Update EV-D22 status: "Awaiting sanitisation"
Physical handling: device moved to locked secure storage (Zone 3 — labelled section)
while awaiting sanitisation — not left in general storage
In the decommissioned section, track:
Date device was decommissioned
Reason: EOL / Failure / Replaced / Upgrade
Sanitisation date (once completed): cross-reference EV-D26
Disposal date (once completed): cross-reference EV-D25
Destruction certificate reference: EV-D25-[ref]
A device appearing in "Awaiting sanitisation" for >90 days:
IT Manager escalates — devices in this state are a liability
Either sanitise and dispose, or document the delay reason
Section 8 — Media sanitisation procedure by media type
8.1 Overview and standards reference
NIST SP 800-88r1 (Guidelines for Media Sanitisation) is the authoritative
reference for sanitisation methods. The methods below are mapped to
NIST 800-88 categories:
Clear: Overwrite data so it cannot be recovered using standard software tools
Appropriate for: media being reused within the organisation
NOT appropriate for: media being disposed of externally
Purge: Apply more rigorous techniques that render data unrecoverable
even by laboratory techniques using current technology
Appropriate for: media being disposed of externally or reused
in lower-security environments
Destroy: Physically destroy the media so that it cannot be used
Appropriate for: all media where recovery of any data is unacceptable
regardless of cost of recovery attempt
CYBER ESSENTIALS AND DEFSTAN REQUIREMENT:
Cyber Essentials: "sanitise storage media before repurposing or disposal"
DEFSTAN Profile 1: "cryptographic erase or physical destruction for all
media that has held OFFICIAL information"
DEFSTAN note on cryptographic erase:
For self-encrypting drives (SEDs): cryptographic erase (key deletion)
is acceptable for DEFSTAN OFFICIAL. It is the fastest and most reliable
method because it does not require overwriting the entire media.
Verify: the drive is genuinely self-encrypting (check manufacturer spec sheet)
before relying on cryptographic erase rather than overwrite.
APPROVED TOOLS:
Windows HDD/SSD: DBAN (Darik's Boot and Nuke) — open source; bootable USB
Eraser (for individual files/volumes)
BitLocker + Format (for encrypted drives — cryptographic erase)
Manufacturer secure erase utilities (vendor-specific)
macOS: Disk Utility → Erase with Security Options
diskutil secureErase (command line)
FileVault + Format (cryptographic erase for encrypted drives)
Linux: shred -vz -n 3 [device] (3-pass overwrite + zero fill)
nwipe (open source; NIST 800-88 compliant options)
hdparm --security-erase (ATA Secure Erase for SSDs)
blkdiscard (TRIM-based erase for SSDs — verify with manufacturer)
Network devices: Manufacturer factory reset + configuration wipe
(verify data is cleared — some factory resets preserve logs)
Physical destruction: Approved data destruction vendor (ADISA-certified)
Internal shredder (DIN 66399 Level P-4 minimum for paper;
E-3 or higher for solid-state media if using internal shredding)
8.2 Sanitisation by media type
═══════════════════════════════════════════════════════════════════════
HARD DISK DRIVES (HDD) — magnetic spinning disk
═══════════════════════════════════════════════════════════════════════
Scenario A — REUSE within the organisation (lower-risk destination):
Method: Clear (single overwrite + verify)
Procedure:
1. Boot target system from DBAN USB (do not boot from the target drive)
2. Select drive in DBAN menu (confirm correct drive — verify by size and model)
3. Method: DoD Short (3 passes: 0x00, 0xFF, random) — acceptable for Clear
OR: Quick Wipe (1 pass random) — acceptable for drives that had non-CUI data
MINIMUM for CUI: DoD Short or higher
4. DBAN confirms completion: note start time, end time, passes completed,
verification result (pass/fail)
5. Label the sanitised drive with a label: "SANITISED [DATE] — [Engineer initials]"
6. Log in EV-D26 (see Section 10 for template)
Tool: DBAN available at: dban.org (verify hash of downloaded ISO before use)
Verify ISO hash before creating USB:
Windows: Get-FileHash -Algorithm SHA256 [dban-iso]
Confirmed against: dban.org/download (SHA256 listed on the download page)
Scenario B — DISPOSAL or REUSE in lower-trust environment:
Method: Purge (NIST 800-88 Purge)
Option B1 — ATA Secure Erase (fastest — use if drive supports it):
Boot from a Linux live USB
Identify drive: lsblk (confirm target drive — do not erase the live USB)
Check if drive supports Secure Erase and is not frozen:
hdparm -I /dev/sdX | grep -i "security"
If drive shows "Security level: high, not frozen":
Set security password: hdparm --security-set-pass P@ssw0rd123 /dev/sdX
Execute Secure Erase: hdparm --security-erase P@ssw0rd123 /dev/sdX
Wait: this takes time proportional to drive size (30 min–several hours)
Verify: hdparm -I /dev/sdX | grep -i "not enabled"
(Security features should show "not enabled" after successful erase)
If drive shows "frozen":
Some BIOS settings freeze the drive at boot — try: power cycle the drive
while system is on (disconnect/reconnect SATA/USB) to unfreeze
If still frozen: use Option B2 (overwrite-based)
Option B2 — Multi-pass overwrite (if ATA Secure Erase not available):
Boot from DBAN USB
Method: PRNG Stream (7 passes) — NIST 800-88 Purge equivalent
OR: DoD 5220.22-M (7 passes)
Note: 7-pass overwrite on a 1TB drive takes many hours — plan accordingly
Record: same as Scenario A (EV-D26)
Option B3 — Physical destruction (where speed is required or drive is faulty):
If the drive is faulty and cannot be sanitised electronically:
Physical destruction is the only option
See HDD physical destruction procedure below
HDD physical destruction (where required):
Method: Shredding (ADISA-certified vendor) OR degaussing + shredding
ADISA requirement: individual asset serial numbers on the certificate
Internal degausser: only if the organisation owns a certified degausser
(most organisations do not — use vendor instead)
Verify vendor: check ADISA-certified company register at adisa.global
═══════════════════════════════════════════════════════════════════════
SOLID STATE DRIVES (SSD), eMMC, USB DRIVES, SD CARDS, NAND FLASH
═══════════════════════════════════════════════════════════════════════
IMPORTANT: Overwrite methods are NOT reliable for SSDs due to wear-levelling.
The write-levelling algorithm in SSDs distributes writes across cells — a
single or multi-pass overwrite does not guarantee all cells are overwritten.
Data may remain in cells that the controller avoided due to wear-levelling.
Scenario A — SSD REUSE within the organisation:
Method: Cryptographic erase (preferred) OR ATA Secure Erase (if supported)
Option A1 — Cryptographic erase (most reliable for SSDs):
ONLY applicable if: the drive was encrypted from first use with BitLocker/FileVault/LUKS
AND the encryption key is not stored on the drive itself
Process:
Delete/rotate the encryption key (the data becomes cryptographically inaccessible)
BitLocker: manage-bde -forcerecovery [drive] then manage-bde -off [drive]
then format the drive (the old encrypted data without the key = unreadable)
FileVault: System Settings → Privacy & Security → FileVault → Turn Off FileVault
then: Disk Utility → Erase
LUKS (Linux): cryptsetup luksErase /dev/sdX (destroys the key slots)
then: wipe the LUKS header (dd if=/dev/urandom of=/dev/sdX bs=1M count=10)
Verify: attempt to mount the drive and read data — should be completely inaccessible
Record in EV-D26: "Cryptographic erase — encryption key deleted — drive reformatted"
This method does not work if: the drive was not encrypted from first use, or if
the drive is a self-encrypting drive (SED) where you deleted the ATA password
but cannot verify the hardware encryption was actually applied from day one.
Option A2 — ATA Secure Erase (for SSDs that support it):
Same procedure as HDD ATA Secure Erase (see above)
Many modern NVMe SSDs support NVMe Sanitize instead:
nvme format /dev/nvme0n1 --ses=1 (Crypto Erase via NVMe format)
OR nvme sanitize /dev/nvme0n1 --sanact=4 (Block Erase sanitize)
Verify: nvme id-ns /dev/nvme0n1 — all logical blocks should read as 0 or erased value
Scenario B — SSD DISPOSAL:
Method: Physical destruction — the only reliable method for disposal of SSDs
This is a firm rule: SSDs containing CUI that are being disposed of must be
physically destroyed. There is no overwrite method that provides the same
assurance as physical destruction for solid-state media.
Physical destruction:
ADISA-certified vendor: preferred for all SSD disposal
Method: industrial shredder reducing to ≤2mm particles (ensures all cells are destroyed)
Internal shredder: only acceptable if the shredder is rated for electronic media
(DIN 66399 Level E-4 or higher) — not all office shredders
are rated for SSDs; verify before using
Note: a shredder that is rated for paper (P-4) is NOT necessarily rated for
electronic media (E-4). These are different certifications. A paper shredder
applied to an SSD may not destroy the memory chips sufficiently.
USB drives:
All USB drives containing CUI: physical destruction (not overwrite)
Reason: USB drive controllers have wear-levelling similar to SSDs
Method: ADISA vendor OR approved internal shredder (E-3 rated minimum)
USB drives being reused internally after non-CUI use only:
Acceptable: full format (not quick format) + USB drive tool overwrite
Not acceptable: quick format alone
SD cards:
Same as USB drives — physical destruction for all disposal
Physical destruction method: shredding (E-3 rated shredder minimum) OR crushing
Some SD card data recovery tools can recover from bent/broken cards —
crushing alone without shredding is not sufficient
═══════════════════════════════════════════════════════════════════════
WINDOWS WORKSTATIONS AND LAPTOPS — FULL SYSTEM WIPE
═══════════════════════════════════════════════════════════════════════
For system wipe before reassignment to a different user (reuse scenario):
Method 1 — Intune Fresh Start / Autopilot Reset (preferred for managed devices):
Intune console → Devices → [device] → Actions → Fresh Start
Removes all user data; reinstalls Windows; re-enrols in Intune
Encryption: BitLocker re-enabled automatically on re-enrolment
Suitable for: reassignment to another employee
Method 2 — Windows Reset with data removal:
Settings → System → Recovery → Reset this PC → Remove everything
Option: "Remove files and clean the drive" (slower but more thorough)
Then: re-enrol in Intune/MDM
Method 3 — Reimaging (for disposal or complete rebuild):
Boot from IT Operations USB imaging stick
Image: apply clean Windows image from SCCM/MDM deployment share
Or: apply DBAN wipe first, then reimage
Suitable for: devices being repurposed to a different function
For disposal after system wipe:
Internal HDD: follow HDD disposal procedure above (Purge)
Internal SSD: follow SSD disposal procedure above (physical destruction)
═══════════════════════════════════════════════════════════════════════
macOS WORKSTATIONS
═══════════════════════════════════════════════════════════════════════
macOS Intel (non-Apple Silicon) — for reassignment:
Erase Mac: System Preferences → [your name] → Sign Out → erase all content
OR: Recovery Mode (hold Cmd+R on boot) → Disk Utility → Erase →
select Startup Disk → Options → select "Most Secure" (7-pass)
Note: macOS Monterey+ offers "Erase All Content and Settings" which
includes a cryptographic erase if FileVault was enabled
macOS Apple Silicon (M1, M2, M3+) — for reassignment:
Recovery Mode (hold power button on boot) → Erase Mac → Erase Mac (confirm)
This performs a cryptographic erase at the chip level (hardware encryption)
Much faster than traditional overwrite; more reliable for SSD
Verify: attempt to boot the device after erase → should show Setup Assistant
(i.e. no user data remains)
macOS — for disposal:
Apple Silicon: same as reassignment (cryptographic erase is sufficient for disposal)
because the encryption is hardware-level and key destruction
is genuine
Intel with SSD: physical destruction (same SSD rule as above)
Intel with HDD: DBAN overwrite then physical destruction for high-sensitivity
═══════════════════════════════════════════════════════════════════════
LINUX SERVERS
═══════════════════════════════════════════════════════════════════════
For reuse (different function, same organisation):
Reimage from Ansible/deployment tooling
The reimage procedure does not sanitise the drive — it overwrites the OS partition
but leaves other partitions potentially accessible
For full sanitisation before server is repurposed:
Boot from live USB (Ubuntu live media or DBAN)
Identify target drives: lsblk
For HDD: nwipe --method=dod --verify=last /dev/sdX
For SSD: ATA Secure Erase (hdparm) or manufacturer tool (see SSD section above)
Then: reimage from Ansible deployment
For disposal:
HDD: nwipe (Purge-equivalent) then physical destruction
SSD/NVMe: physical destruction (ADISA vendor)
LUKS-encrypted drives (if LUKS was applied from first deployment):
Cryptographic erase acceptable — destroy LUKS header:
dd if=/dev/urandom of=/dev/sdX bs=512 count=512 conv=noerror
(This overwrites the LUKS header — without the header, encrypted data is unreadable)
Then: dispose via ADISA vendor for physical destruction
═══════════════════════════════════════════════════════════════════════
MOBILE DEVICES (smartphones and tablets)
═══════════════════════════════════════════════════════════════════════
For reassignment within organisation:
MDM (Intune): Devices → [device] → Wipe
Select: "Wipe device" (not "Retire" — Retire only removes company data)
For iOS: also ensure "Return activation lock" is selected if using Supervised mode
Wait for device to complete factory reset and confirm in MDM console
For iOS devices: MDM wipe performs a cryptographic erase (Apple's built-in
hardware encryption key is deleted) — this is reliable and appropriate
For Android enterprise devices: MDM wipe performs a factory reset
Samsung Knox / Android Enterprise: cryptographic erase via MDM
For disposal:
Perform MDM wipe as above
Additionally: remove SIM card (return to IT Operations for shredding or disposal)
Additionally: ensure Find My iPhone / Find My Device is disabled (prevents activation lock)
Physical device: if screen is broken, ensure MDM wipe completed before physical disposal
For Pixel devices or high-security requirements: physical destruction of the device
(the storage chip is on the main board — board-level shredding ensures complete destruction)
═══════════════════════════════════════════════════════════════════════
NETWORK DEVICES (firewalls, routers, managed switches)
═══════════════════════════════════════════════════════════════════════
For reassignment or disposal:
Step 1 — Export configuration for records (before wiping):
Export running configuration to git repository (OP-03)
This preserves the configuration for audit trail
Do NOT skip this step — the export is evidence of what was configured
Step 2 — Factory reset:
Follow vendor-specific procedure to perform full factory reset
Examples:
Palo Alto: Device → Setup → Operations → Factory Reset
Cisco IOS: write erase then reload
FortiGate: exec factoryreset (confirms twice before proceeding)
Ubiquiti: hardware reset button (hold 10 seconds on most models)
Factory reset removes: configuration, logs, credentials
Factory reset does NOT always remove: firmware (remains; acceptable)
Verify after reset: attempt management access with factory default credentials
Device should require initial setup — confirms wipe was successful
Step 3 — For disposal:
After factory reset: physical destruction is generally not required
unless the device's non-volatile memory is known to contain persistent CUI
Most network device flash storage only retains configuration, not CUI data
Exception: if the network device was used as a VPN endpoint and session logs
are stored on the device: review vendor documentation to confirm factory
reset clears session logs; if uncertain, add to ADISA vendor disposal batch
Step 4 — Log in EV-D26:
Record: device, factory reset date, who performed it, method
═══════════════════════════════════════════════════════════════════════
OPTICAL MEDIA (CDs, DVDs)
═══════════════════════════════════════════════════════════════════════
CUI on optical media: physical destruction only (cannot be overwritten)
Method: cross-cut shredder rated for optical media (DIN 66399 Level O-4)
OR: scratch the surface with sandpaper across the data layer (less preferred;
potential partial data recovery — not acceptable for CUI)
OR: ADISA vendor (batch optical media destruction)
Record in EV-D26: asset ID (if tracked), type (CD/DVD), destruction method, date, engineer
If CUI was burned to a disc and the disc was produced for external sharing:
This is an AT-SC-ENC and AT-MP policy matter — burning CUI to optical disc
for external sharing should not happen without CISO approval
Any such discs should be tracked and recovered or destroyed after use
═══════════════════════════════════════════════════════════════════════
PAPER DOCUMENTS
═══════════════════════════════════════════════════════════════════════
Classification: CUI / OFFICIAL (any printed documents containing CUI)
Routine paper CUI: cross-cut office shredder (DIN 66399 Level P-4)
P-4 produces: maximum particle size 160mm², strip width ≤6mm
P-4 is the minimum for CUI — standard strip-cut shredders (P-1, P-2) are NOT acceptable
Acceptable shredder types: cross-cut, micro-cut (P-5, P-6, P-7)
Not acceptable: strip-cut / particle cut below P-4
Shredder bin: empty into locked confidential waste bin (grey/red locked bin)
Collection: contracted confidential waste company; certificate per collection
High-volume paper CUI disposal (clearouts, document archives):
Confidential waste company: bags/consignment boxes with tamper-evident seals
Seal the box/bag yourself — the seal number is recorded by the waste company
Certificate: issued per collection; includes consignment seal numbers
For OFFICIAL-SENSITIVE equivalent paper documents:
Minimum: P-5 micro-cut (particles ≤30mm², strip width ≤2.5mm)
Preferred: P-6 or P-7 for highest sensitivity
Section 9 — Destruction certificate process (EV-D25)
9.1 When a destruction certificate is required
A destruction certificate (EV-D25) is required for every disposal event
where a CUI-scope physical asset is physically destroyed or handed to
a third party for destruction.
MANDATORY — EV-D25 required:
Every CUI-scope device sent to an ADISA-certified vendor for destruction
Every CUI-scope device where physical shredding is witnessed and certified
Every device in EV-D22 that is marked CUI-scope and moves to "Disposed" status
DEFSTAN requirement: each certificate must list individual asset serial numbers
A batch certificate ("200 HDDs destroyed on [date]") is NOT acceptable
for DEFSTAN purposes — each asset serial number must appear individually
If your disposal vendor only provides batch certificates: negotiate per-asset
certificates or change vendor. An ADISA-certified vendor should be able to
provide per-asset certificates as standard.
NOT required (but document in EV-D26):
Internal sanitisation for reuse within the organisation (no disposal occurs)
Paper document shredding via office shredder (covered by waste company certificate
at collection level — not per-document; no individual asset tracking)
ADISA CERTIFICATION:
ADISA (Asset Disposal & Information Security Alliance) certifies IT disposal vendors
Verify your disposal vendor is certified: adisa.global → Find a member
ADISA certification confirms: the vendor uses approved processes; staff are
vetted; chain of custody is maintained; certificates are reliable
Non-ADISA vendor: not acceptable for CUI-scope device disposal
IT charity donations (e.g. Computer Aid): only if ADISA-certified AND
device is fully sanitised (preferably physical destruction) before transfer
9.2 Destruction certificate procedure
STEP 1 — PREPARE ASSET FOR DISPOSAL:
Confirm device is in EV-D22 as CUI-scope:
Pull up the EV-D22 record for the asset
Verify: CUI scope = Yes; Status = Awaiting sanitisation
Record: serial number from EV-D22 must match the physical device label
Physical check before handover:
Remove any company asset tags (peel off; do not obscure serial number label)
Keep the manufacturer serial number label intact (vendor uses this for certificate)
Remove any removable media that should be handled separately:
Any separately removable SSD or HDD trays: treat as a separate asset
RAM: does not require a destruction certificate (no persistent storage)
Optical drives (internal): does not require a certificate (no stored data
unless used as a burner — if used as a burner with CUI optical media,
note in EV-D26 that the drive was used and the media was destroyed)
STEP 2 — COMPLETE AN ASSET LIST FOR THE VENDOR:
Before the collection or drop-off, compile:
Asset list document (provided to vendor at handover):
Organisation name: [organisation name]
Date of handover: [YYYY-MM-DD]
Reference number: EV-D25-[YYYY-NNN] (pre-assign a reference before handover)
| Asset ID | Asset Type | Manufacturer | Model | Serial Number | EV-D22 Ref |
| [ORG-LT-0042] | [Laptop] | [Dell] | [Latitude 5520] | [SN12345678] | [EV-D22-042] |
| [continue for each asset] |
This document: signed by IT Manager at handover; copy retained in EV-D25 folder
Vendor: countersigns the asset list at receipt (chain of custody established)
The vendor's certificate should reference the same serial numbers as this list
If the vendor's certificate uses different identifiers: request alignment
before accepting the certificate
STEP 3 — HANDOVER:
Drop-off or collection:
Collection: vendor collects from site; IT Operations hands over in person;
obtain a signed receipt from the vendor representative at collection
(Receipt = vendor's name, date, asset count, signature)
Drop-off: IT Operations delivers to vendor facility; obtain signed receipt at drop-off
During transit (for collection by vendor):
All devices must be in a secured, closed container
Do NOT leave devices unsecured in vehicles unattended
For high-value assets or large batches: consider courier tracking
STEP 4 — RECEIVE AND FILE THE CERTIFICATE:
Certificate arrives from vendor: typically 2–5 business days after destruction
Verify the certificate contains:
□ Vendor company name and ADISA certificate number
□ Date of destruction
□ Each asset listed by serial number (NOT batch total — individual items)
□ Destruction method used (shredding / degaussing + shredding / crushing)
□ Vendor representative signature
□ Your organisation's name and the handover reference number
If the certificate is missing any of the above:
Contact the vendor and request a corrected certificate
Do not file an incomplete certificate — it will fail a DEFSTAN assessment
Cross-reference:
Every serial number on the certificate must match an asset in EV-D22
Any serial number on the certificate not in EV-D22: investigate —
was this an unregistered asset? If so, add to EV-D22 retroactively
Any serial number in EV-D22 awaiting disposal but NOT on the certificate:
contact vendor — possible that one asset was missed; do not mark as disposed
until confirmed
STEP 5 — UPDATE RECORDS:
EV-D22 update (for each asset on the certificate):
Status: Disposed
Disposal date: [date on destruction certificate]
Disposal method: Vendor destruction — [vendor name]
Destruction cert ref: EV-D25-[YYYY-NNN]
File the certificate:
EV-D25 folder: EV-D → Physical Security → Destruction Certificates → [YYYY]
File as: EV-D25-[YYYY-NNN]-[VendorName]-[YYYY-MM-DD].pdf
Retention: PERMANENT (destruction certificates are never deleted)
DEFSTAN contracts: retain indefinitely while the contract is active
and for the period the contracting authority may audit (confirm with CISO)
EMERGENCY DESTRUCTION (device must be destroyed urgently):
Trigger: device is compromised; incident response requires immediate media destruction;
stolen device has been recovered but is untrustworthy; ransomware device
If immediate destruction is required and ADISA vendor cannot respond in time:
Internal destruction is acceptable in emergencies:
Physical: drill through the storage components (HDD platters; SSD circuit board)
Or: industrial-grade hammer applied to internal components
IT Operations documents this with photographs as evidence
ADISA certificate is not available for emergency destruction:
Document in EV-D26: emergency destruction, method, witnesses, date
Include photographs in EV-D26 filing
Notify CISO: emergency destruction occurred; update EV-D22 to "Disposed"
Note for DEFSTAN: emergency destruction without ADISA certificate may
require explanation to the contracting authority if the asset was
associated with DEFSTAN contract data — CISO manages this communication
Section 10 — Internal sanitisation log (EV-D26)
10.1 When EV-D26 is required
EV-D26 records every sanitisation event performed in-house by IT Operations.
This is distinct from EV-D25 (destruction certificates from vendors).
EV-D26 is required for:
Internal overwrite sanitisation (HDD being reused within the organisation)
Cryptographic erase (BitLocker/FileVault key deletion for reuse)
Internal ATA Secure Erase performed by IT Operations
Internal physical destruction (e.g. emergency drilling/hammering)
On-site paper shredding of CUI documents
Network device factory resets before disposal or reuse
EV-D26 is NOT a replacement for EV-D25:
If the device goes to an ADISA vendor, EV-D25 is the certificate
EV-D26 documents the internal sanitisation step BEFORE the vendor
receives the device (e.g. you overwrite in-house, then vendor shreds)
Both EV-D26 and EV-D25 are created; they cross-reference each other
10.2 EV-D26 record template
EV-D26 entries are maintained in a single rolling log document
filed at: EV-D → Physical Security → Media Sanitisation Log
One entry per sanitisation event (one device = one event):
EV-D26 ENTRY
Entry number: EV-D26-YYYY-NNN (sequential within year)
Date of sanitisation: YYYY-MM-DD
Sanitisation engineer: [Full name of IT Operations engineer]
Witness (if required): [Name — required for CUI-scope device disposal;
not required for reuse sanitisation]
ASSET DETAILS:
Asset ID: [from EV-D22]
Asset type: [Laptop / Desktop / Server / USB / etc.]
Manufacturer: [Brand]
Model: [Model]
Serial number: [Full serial number — verify against EV-D22 entry]
Storage type: [HDD / SSD / USB flash / SD / eMMC / etc.]
Storage capacity: [e.g. 512GB]
CUI scope: Yes / No
Was CUI stored on this device? Yes / No / Unknown (assume Yes if uncertain)
SANITISATION DETAILS:
Method applied: [Select one]
□ NIST 800-88 Clear — single pass overwrite
□ NIST 800-88 Purge — multi-pass overwrite (specify passes: [N])
□ NIST 800-88 Purge — ATA Secure Erase
□ NIST 800-88 Purge — NVMe Sanitize
□ Cryptographic erase — BitLocker key deletion + reformat
□ Cryptographic erase — FileVault key deletion + reformat
□ Cryptographic erase — LUKS header destruction
□ Factory reset — network device (specify device type: [type])
□ Factory reset — mobile device via MDM
□ Physical destruction — drilled/crushed in-house (attach photographs)
□ Paper shredding — DIN 66399 Level [P-4/P-5/P-6] (specify)
□ Other: [describe precisely]
Tool used (for software methods):
[DBAN version X.Y / nwipe version X.Y / hdparm version X.Y /
macOS Disk Utility version X.Y / Intune Wipe / etc.]
Parameters (for overwrite methods):
Number of passes: [N]
Overwrite pattern: [Random / DoD / Zero / etc.]
Verification pass: Yes / No (verify verifies overwrite; highly recommended)
Start time: [HH:MM]
End time: [HH:MM]
Duration: [HH hours MM minutes]
RESULT:
Sanitisation result: Success / Failure
If failure: [describe what happened; what was done instead]
Verification result (if verification pass was selected):
Tool reported: [Pass / Fail / Not applicable]
Post-sanitisation label applied to device:
Yes — "SANITISED [YYYY-MM-DD] [Engineer initials]"
No — [explain why not; this is unusual and should be explained]
NEXT ACTION:
Device disposition after sanitisation:
□ Reuse within organisation — assigned to: [name or "IT pool"]
□ Sent to ADISA vendor for physical destruction — vendor: [name]
EV-D25 reference (once certificate received): [EV-D25-YYYY-NNN]
□ Awaiting further decision — held in secure storage Zone 3
□ Emergency in-house destruction — photographs attached: Yes
EV-D22 updated: Yes / No (must be Yes before filing EV-D26)
EV-D22 status updated to: [Reissued / Awaiting disposal / Disposed]
Engineer signature: _________________ Date: _________
Witness signature (where required): _____________ Date: _________
File at: EV-D → Physical Security → Media Sanitisation Log
[append to rolling annual log document — EV-D26-[YYYY].docx]
Section 11 — Removable media policy and technical enforcement
11.1 Default position and enforcement
DEFAULT POLICY: USB mass storage devices are BLOCKED on all CUI-scope systems.
This is the strongest implementation of 3.8.7 — it removes the attack vector
entirely (malware delivery, data exfiltration, device loss) without requiring
ongoing per-media monitoring.
TECHNICAL ENFORCEMENT:
Windows (GPO):
Policy path:
Computer Configuration → Administrative Templates → System →
Removable Storage Access
Settings (all to: Enabled):
All Removable Storage classes: Deny all access
CD and DVD: Deny all access
Custom Classes: Deny all access
Floppy Drives: Deny all access
Removable Disks: Deny all access
Tape Drives: Deny all access
WPD Devices: Deny all access (Windows Portable Devices — phones, cameras)
Apply GPO to: OU=Workstations,OU=CUI-Scope AND OU=Servers,OU=CUI-Scope
Verify:
On a CUI-scope Windows device: plug in a standard USB drive
Expected: "Access is denied" or "This device is restricted by IT policy"
Device should not appear in File Explorer
If device appears: GPO may not have applied — run gpupdate /force
and check GPO scope via gpresult /r
macOS (MDM Configuration Profile):
Payload: Restrictions
allowExternalStorage: false (iOS/iPadOS) — prevents external storage mounting
For macOS laptops (not iOS — macOS restrictions profiles differ):
Use third-party MDM restriction or [EDR product] USB control feature
Most commercial EDR products support USB device control policies
Configure: block all USB mass storage; allow HID (keyboards/mice)
Example (Microsoft Defender for Endpoint macOS USB policy):
Settings catalog → Device Control:
Removable media (All): Blocked
Keyboards and Mice: Allowed
Verify: plug USB drive into MDM-enrolled macOS device
Expected: drive does not mount (may not appear in Finder or appears briefly then disappears)
If Finder shows the drive: EDR device control policy not active — investigate
Linux (udev rules via Ansible):
# /etc/udev/rules.d/99-usb-block.rules
# Deployed via Ansible av_agent role or dedicated ansible role: usb_control
SUBSYSTEM=="block", ATTRS{removable}=="1", ACTION=="add", RUN+="/bin/sh -c 'echo 1 > /sys$DEVPATH/authorized && echo 0 > /sys$DEVPATH/authorized'"
# Simpler approach using udisks2 policy:
# /etc/polkit-1/localauthority/50-local.d/10-storage-block.pkla
[Deny USB storage]
Identity=unix-user:*
Action=org.freedesktop.udisks2.filesystem-mount
ResultAny=no
ResultInactive=no
ResultActive=no
Verify: plug USB drive into CUI-scope Linux server
Expected: drive does not auto-mount; no desktop notification
Manual mount attempt: mount /dev/sdb1 /mnt/usb
Expected: Permission denied
SIEM ALERT ON USB CONNECTION ATTEMPT:
Even with block policy in effect: log USB connection attempts
Windows:
Event 6416: A new external device was recognized by the system
Forward to SIEM: WEF subscription includes EventID 6416
SIEM alert: Medium severity — USB device connected to CUI-scope system
(Alert even though device is blocked — understand what is being attempted)
SIEM alert rule for USB:
Source: Windows Security event log or EDR event
Condition: USB mass storage device connected to CUI-scope device
Severity: Medium
Action: IT Operations review; confirm block was applied; investigate if
user was attempting to use USB (policy awareness issue)
or if USB was plugged in without user awareness (physical security concern)
11.2 USB exception procedure
When a legitimate business need requires USB access on a CUI-scope system:
APPROVED USB EXCEPTION CATEGORIES:
Category 1 — IT Operations managed USB drives:
Approved for: imaging, BIOS updates, diagnostic tools, DBAN media
Control: IT Operations-owned drives; logged in EV-D22; used by IT staff only
Process: no exception required — these are approved IT Operations tools
The drives are controlled items; not for general staff use
Category 2 — Data transfer with specific business justification:
Rare; requires CISO approval
Process: ITSM ticket → IT Manager → CISO approval → time-limited exception
Duration: exception valid for the specific transfer only; revoked after completion
Technical implementation of exception (Windows):
Intune Device Configuration → [policy] → Removable media:
Or: add the specific device's hardware ID to an allow list
Hardware ID: obtained by plugging the drive into a non-CUI system first
Device Manager → [USB drive] → Properties → Details → Hardware IDs
Example: USBSTOR\DiskSandisk_Cruzer_________8.01
Add to allowlist in policy; deploy to specific device; time-limit if possible
Note EV-D22: the specific approved USB drive must be registered
Before use: IT Operations scans the USB drive for malware (on-demand AV scan)
After use: exception is revoked; USB drive re-registered or destroyed
Category 3 — Peripheral devices (keyboards, mice, headsets):
These are HID (Human Interface Devices), not mass storage
HID devices are NOT blocked by the USB mass storage block policy
They connect as HID class, not as USBSTOR class
No exception required for IT-approved peripherals
Exception: some peripherals contain embedded storage (e.g. wireless receivers
with firmware storage) — if the AV alert flags these as removable storage,
work with the vendor on a hardware ID allowlist entry
OWNER-IDENTIFIED USB (3.8.8 — prohibit anonymous storage devices):
All USB drives in organisational use must be registered in EV-D22
No anonymous (untracked) USB drives permitted on CUI-scope systems
A USB drive without an asset ID and owner in EV-D22 is prohibited
Found USB drive on premises (not assigned to any user):
Do NOT plug it into any computer — potential malware delivery
Report to IT Operations: treat as a security concern
IT Operations: scan on an isolated, non-CUI device
CISO: determine origin; if unknown, destroy the drive (EV-D26)
Section 12 — Evidence generation and maintenance
12.1 Evidence register for FC-06 and FC-07
| Evidence ID | What to produce | Controls satisfied | Frequency | Owner | Filed at |
|---|---|---|---|---|---|
| EV-D22 | Asset register — media section: all physical assets, encryption status, CUI scope, disposal status, cert references | 3.8.1, 3.8.2, 3.8.4, 3.8.7, 3.8.8 · PE 3.10.x | Continuous; quarterly reconciliation | IT Operations | EV-D → Config Management → Asset Register |
| EV-D23 | Quarterly physical access review — ACS export vs HR export; Zone 3 access list | PE.L1-3.10.1, 3.10.2, 3.10.4, 3.10.5 · ISO 27001 A.7.1, A.7.2 | Quarterly | Facilities Manager + IT Manager | EV-D → Physical Security → Access Logs → [YYYY-QQ] |
| EV-D24 | Contractor/maintenance visit record — per visit; escorted access; CUI protection actions | PE.L1-3.10.3, 3.10.6 · DEFSTAN P1 §Maintenance | Per visit | IT Operations | EV-D → Physical Security → Contractor Records |
| EV-D25 | Destruction certificates — per asset; individual serial numbers; ADISA certified; permanent retention | MP.L1-3.8.3 · ISO 27001 A.7.14 · DEFSTAN P1 §Physical | Per disposal event; PERMANENT | IT Manager | EV-D → Physical Security → Destruction Certificates |
| EV-D26 | Internal sanitisation log — per sanitisation event; tool, method, result, engineer, witness | MP.L1-3.8.3 · ISO 27001 A.7.14, A.8.10 | Per sanitisation event; PERMANENT | IT Operations | EV-D → Physical Security → Media Sanitisation Log |
| EV-D29 | Monthly CCTV health check — camera status, recording verification, access review | PE.L1-3.10.2, 3.10.4 · ISO 27001 A.7.4 | Monthly | Facilities Manager | EV-D → Physical Security → CCTV Records |
12.2 Evidence production calendar
DAILY:
[ ] Zone 3 after-hours SIEM alerts: review any overnight access events
[ ] Visitor sign-out: confirm all visitors from today have signed out
[ ] USB connection alerts: review SIEM queue for any USB connection events
WEEKLY:
[ ] ACS event log: spot-check for anomalous access patterns
[ ] Decommissioned device queue: any devices awaiting sanitisation for >30 days?
(Devices awaiting disposal represent a residual data risk — resolve promptly)
MONTHLY:
[ ] EV-D29: CCTV health check (by 5th of each month)
[ ] Media register (EV-D22): any new assets not yet registered?
Any assets whose status has changed and not been updated?
[ ] Visitor log: archive previous month; confirm sign-out completion
QUARTERLY:
[ ] EV-D23: physical access review (ACS vs HR cross-reference; Zone 3 list)
[ ] EV-D22: physical reconciliation (locate every CUI-scope asset)
[ ] EV-D25 / EV-D26 review: any devices in EV-D22 marked
"Awaiting disposal" for >90 days? Escalate to IT Manager
[ ] CCTV: playback test; DVR access review
[ ] ACS system: firmware update check; review any failed access events for patterns
ANNUALLY:
[ ] Physical security architecture review: zone model still appropriate?
Any new doors, rooms, or access points not yet covered?
[ ] ADISA vendor review: is the current disposal vendor still ADISA-certified?
Check adisa.global for current certification status
[ ] Shredder maintenance: confirm office shredder is DIN P-4 rated; serviced
[ ] Media register completeness: 100% of CUI-scope assets in EV-D22?
[ ] Zone 3 access list annual re-approval: CISO re-approves each member annually
(Quarterly review maintains the list; annual review is a formal CISO sign-off)
PER EVENT:
[ ] New employee: access card provisioned before first day; EV-D03 updated
[ ] Departing employee: card deactivated within 1 hour; EV-D03 updated;
EV-D04 physical access section signed
[ ] New device acquired: EV-D22 entry created before device is issued
[ ] Device decommissioned: EV-D22 status changed to "Awaiting sanitisation";
device physically moved to locked secure storage
[ ] Sanitisation performed: EV-D26 entry completed; EV-D22 status updated
[ ] Disposal vendor collection: asset list signed and retained;
EV-D25 folder reference pre-assigned; wait for certificate
[ ] Destruction certificate received: EV-D25 filed; EV-D22 updated to "Disposed"
[ ] Visitor with Zone 3 requirement: ITSM ticket opened; EV-D24 completed
[ ] Lost/stolen device: EV-D22 status = Lost; IT Manager + CISO notified;
AT-IR incident opened; ICO 72-hour clock assessed by CISO
12.3 Pre-assessment quality checks
Run these checks 2 weeks before any C3PAO, Cyber Essentials+, or DEFSTAN assessment:
FOR PHYSICAL PROTECTION (FC-06):
□ EV-D23 is current (within 90 days) — quarterly review completed on schedule
□ Zone 3 access list matches current ACS cardholder records
□ No orphaned ACS cards found in most recent quarterly review
□ All contractor visits in the past 12 months have an EV-D24 record
□ EV-D29 is current for the past 3 months (monthly checks confirmed)
□ CCTV: cameras operational; footage accessible for past 31 days
□ Visitor log: past 12 months of visitor records are available
□ ACS is configured to deny access outside business hours to Zone 3 for
standard staff (only IT Operations and CISO can access Zone 3 after hours)
FOR MEDIA PROTECTION (FC-07):
□ EV-D22 is current — all CUI-scope assets are in the register
□ Quarterly physical reconciliation completed within past 90 days
□ All devices marked "Disposed" in EV-D22 have an EV-D25 certificate reference
□ All EV-D25 certificates: each one lists individual serial numbers (not batch)
□ All EV-D25 certificates: filed permanently; oldest certificates accessible
□ EV-D26 has an entry for every internal sanitisation event
□ No CUI-scope devices in "Awaiting sanitisation" status for >90 days
□ USB block is active on all CUI-scope Windows devices:
gpresult /r on sample devices → confirms USB block GPO is applying
□ USB block is active on all CUI-scope macOS devices:
MDM console → Device compliance → USB policy applied: Yes
□ AV scan of any approved USB drives used since last review
□ Paper shredder: confirm DIN P-4 or higher rating; shredder is operational
DEFSTAN-SPECIFIC CHECKS:
□ EV-D25 certificates reference individual asset serial numbers
(Not batch quantities — this is the most common DEFSTAN finding in MP)
□ Disposal vendor is ADISA-certified — verify current certificate at adisa.global
□ EV-D24 records exist for all contractor visits to Zone 3 areas
where OFFICIAL information is processed
□ Zone 3 supervision records: confirm all non-BPSS contractors were supervised
□ Non-electronic (paper) CUI: confirm confidential waste company provides
per-collection destruction certificates (not just a contract SLA)
FC-06 and FC-07 IT Staff Technical Procedures — Owner: IT Manager (FC-07) + Facilities Manager (FC-06). Related pages: AT-PE · Physical Protection (advanced tier), AT-MP · Media Protection (advanced tier), AT-PS · Personnel Security (screening and leaver controls), AT-IR · Incident Response (lost/stolen device procedure). Evidence produced: EV-D22, EV-D23, EV-D24, EV-D25, EV-D26, EV-D29. Questions: IT Manager or CISO.