Part 1 · assessment and mitigation recommendations · published v1.0 · 14 October 2026
A lost device or physical-access gap exposes useful information
SC11 · Offices · transport · facilities · shared workplaces
What really happened
An ICO announcement republished in October 2018 described a £120,000 fine after a Heathrow employee lost a USB memory stick in 2017, alongside shortcomings in data-protection practices.
ICO announcement republished by WiredGov, 8 October 2018
Evidence limit: This is a loss-and-control-failure example, not evidence of a successful building intrusion. The physical-entry route below is a separate hypothetical client scenario.
The question for the client
Could someone obtain sensitive information or access through a lost device, visitor process or unattended workspace?
Business impact: Disclosure of sensitive business information, follow-on impersonation and possible unauthorised system access.
- Systems involved
- Visitor/badge controls, workstations, portable storage, data encryption, disposal and physical incident logs.
- Where people fit
- Reception, facilities, contractors and staff handle access and portable information; clear verification and device controls reduce reliance on vigilance alone.
How a similar risk could develop here
Proposed client threat model, not a reconstruction of undocumented incident details.
Obtain a lost device or exploit a permitted-access weakness → reach information or a workspace → use exposed material or an unlocked endpoint to widen access.
Each route depends on several controls. If one stage is blocked, later checks can only continue as a separately authorised, clearly labelled assumed-compromise test. Do not claim an end-to-end attack succeeded merely because a downstream test identity was supplied.
Referenced attack-vector guides
Approval is specific, never inherited from the guide. Check the client, campaign, individual person/asset, method, channel, time window and risk ceiling. Deny overrides allow; absent, expired or withdrawn permission blocks the action. LOW/MED/HIGH describe proposed test impact, not permission or finding severity.
Read the approval rules.
Assessment playbook · Part 1
Start with G01 scope and Target Management, G02 intelligence gathering where needed, and G03 tool/resource preflight. Each selected vector receives its own scoped invocation record.
SC11-S01LOW · proposed test impact1. Review approved controls
Inspect visitor/device policies and evidence of enforcement without attempting entry.
- Why this is needed
- It tests a barrier in the route above and helps answer: Could someone obtain sensitive information or access through a lost device, visitor process or unattended workspace?
- Vector / method
- Tools and guides
- Facilities and device-policy records · client/operator supplied
- Repository input
- physical-checklist.csv · RES-021 · published assessment resource; pin its version/hash in the case record.
- Output
- Control and scope report; attach evidence, target ID, vector version and approval revision.
- Measure
- Selected controls evidenced / applicable selected controls. Agree the acceptance threshold before testing; state raw counts, denominator, conditions and limitations. Compare prohibited cases with a permitted/clean control.
- Current result
- NOT ASSESSED. This is a prepared playbook; no client test or finding is being invented.
- Recommendation on failure
- Clarify visitor/device ownership and evidence that controls operate. Define an observable acceptance criterion for a later retest. No implementation work is allocated now.
SC11-S02HIGH · proposed test impact2. Specific physical exercise only if allowed
Use named approved sites, methods, operator, escort and test badge. If building entry is prohibited, record it not authorised and use the separately approved review instead.
- Why this is needed
- It tests a barrier in the route above and helps answer: Could someone obtain sensitive information or access through a lost device, visitor process or unattended workspace?
- Vector / method
- Tools and guides
- Facilities console and approved test badge · client/operator supplied
- Repository input
- physical-checklist.csv · RES-021 · published assessment resource; pin its version/hash in the case record.
- Output
- Access decisions and limitations; attach evidence, target ID, vector version and approval revision.
- Measure
- Approved cases correctly challenged / executed cases. Agree the acceptance threshold before testing; state raw counts, denominator, conditions and limitations. Compare prohibited cases with a permitted/clean control.
- Current result
- NOT ASSESSED. This is a prepared playbook; no client test or finding is being invented.
- Recommendation on failure
- Improve the failed visitor-verification, escort or badge-lifecycle control; retain explicit physical exclusions. Define an observable acceptance criterion for a later retest. No implementation work is allocated now.
SC11-S03MED · proposed test impact3. Benign removable-media fixture
Use an inert canary and a client test endpoint to check device access, logging and data protection; no executable payload is required.
- Why this is needed
- It tests a barrier in the route above and helps answer: Could someone obtain sensitive information or access through a lost device, visitor process or unattended workspace?
- Vector / method
- Tools and guides
- Client endpoint/device-control console · client/operator supplied
- Repository input
- canary.txt · RES-022 · published assessment resource; pin its version/hash in the case record.
- Output
- Device-control evidence; attach evidence, target ID, vector version and approval revision.
- Measure
- Expected device/data protections enforced / executed cases. Agree the acceptance threshold before testing; state raw counts, denominator, conditions and limitations. Compare prohibited cases with a permitted/clean control.
- Current result
- NOT ASSESSED. This is a prepared playbook; no client test or finding is being invented.
- Recommendation on failure
- Improve the missing media restriction, portable-data protection or event logging without deploying an executable payload. Define an observable acceptance criterion for a later retest. No implementation work is allocated now.
Use one step-result record per case and G06 reporting for the client deliverable. The report must explain successes, failures, uncertainty, prohibitions and coverage limits.
Recommendations to reduce the risk
Reduce the likelihood: Improve visitor verification, temporary-access expiry, portable-data protection and secure working practices.
Reduce the impact if it happens: Minimise sensitive data on portable devices, limit workstation privileges and make loss/access reporting prompt.
How to verify improvement later: repeat the failed control case and a permitted/clean comparison using the same agreed measure; compare conditions and evidence. A better test pass rate alone is not a quantified reduction in business risk.
End of Part 1: evidence-backed findings and mitigation recommendations. The implementation action plan, allocated work, commercial service packaging and costs are deliberately deferred.
Supporting TenguProtect capabilities
Baseline from the 13 October operational audit. This does not claim the complete service is ready or that permissions are already enforced across every agent.
| Capability | Observed readiness | Remaining gap |
|---|
| Physical access, badges and removable media | Hardware and operator dependent; not ready as a packaged service | Verify devices, badge technologies, local operator availability and facilities-approved scenarios. Existing Flipper/Pineapple references do not prove delivery. |
| Security governance, suppliers and staff lifecycle | Content and advisory components; repeatable delivery unproven | Define the exact advisory scope, evidence requests, reviewer competence and report. Do not imply accreditation or legal compliance from a checklist. |
| Incident investigation and timeline analysis | Bounded analyst review available; new-case delivery unproven | Prove a fresh isolated case import/export, permissions, timezone handling and retention. Existing corpus activity is not proof of a new client workflow. |