Somewhere around week three of audit prep, a request lands in your queue that has nothing to do with anything you own.
“Please provide badge access logs for the server room, January through June, along with evidence of quarterly access review.”
You run pipelines. You manage IAM roles and secrets and Kubernetes RBAC. You do not manage doors. But the auditor asked you, because you’re the one who’s been answering every other CC6 request, and because in most companies there is no single person whose job is “physical security evidence.” There is a facilities manager who has a badge system, an IT lead who has a spreadsheet, and a compliance owner who assumed you had it covered.
This gap is now yours to close. Here’s what the frameworks actually require, what the auditor will actually test, and how to handle it without turning it into a six-week fire drill.
Why this lands on platform teams at all
The intuitive objection is: we’re fully in the cloud, AWS owns physical security, this isn’t in scope.
Partly true, and the “partly” is where teams get exceptions.
Your cloud provider covers the data centers running your workloads. You inherit those controls through their SOC 2 report, and you carry that inheritance by reviewing the report annually and documenting it. What you do not inherit is everything else inside your audit boundary:
- Your office, if production access happens from it
- Any colo cage or on-prem rack you still have, including the “temporary” one from three years ago
- Server closets and network rooms in every location
- Endpoint devices — laptops that hold production credentials
- Backup media, if you still have any physical media
- Your visitor process, because a stranger sitting unescorted next to an engineer’s unlocked laptop is a physical access failure
Cloud migration narrowed the physical scope. It did not eliminate it. And the residual scope tends to be the part nobody has instrumented, which is exactly why it generates findings.
What SOC 2 actually says
SOC 2’s Common Criteria series CC6 covers logical and physical access together. That pairing is deliberate: the framework treats a person walking into your network room the same way it treats a person authenticating into your VPC. Both are access. Both need authorization, monitoring, and revocation.
Two sub-criteria carry most of the physical weight:
CC6.4 — restricting physical access to facilities, data centers, backup media storage, and other sensitive locations to authorized personnel. The auditor is testing whether access is granted through an authorization process, reviewed on a defined cadence, and removed when it’s no longer needed.
CC6.5 — that you’ve removed data and software from physical assets before disposal or reuse. This is your laptop offboarding and drive destruction process.
CC6 is consistently one of the highest-exception areas in SOC 2 audits, and the physical sub-criteria contribute more than their share. The pattern is almost always the same: the control exists in reality, but the evidence trail doesn’t. Someone does check who has server room access. They just do it by walking over and asking, and there is no artifact.
Worth internalizing: SOC 2 does not hand you a control list. It gives you criteria, and you design controls to meet them, then get tested against your own stated policy. If your policy says quarterly physical access reviews and you did three in twelve months, that’s an exception — even though nothing in the framework specified quarterly. The most common self-inflicted wound in SOC 2 prep is writing an ambitious policy and then operating a realistic one.
What ISO 27001:2022 actually says
ISO 27001:2022 restructured Annex A into four themes. Theme 7 is Physical Controls: fourteen controls, A.7.1 through A.7.14.
The ones that matter most for a technical team:
- A.7.1 Physical security perimeters — defined boundaries around areas containing information processing facilities
- A.7.2 Physical entry — controls ensuring only authorized people enter secure areas
- A.7.3 Securing offices, rooms and facilities
- A.7.4 Physical security monitoring
- A.7.9 Security of assets off-premises — relevant to every remote engineer with a company laptop
- A.7.14 Secure disposal or re-use of equipment
A.7.4 deserves specific attention because it’s new in the 2022 revision. The 2013 version was satisfied by barriers, locks, and badge readers — prevention. A.7.4 added monitoring: you’re expected to actively detect unauthorized physical access, not just try to prevent it and log entries for later.
The control is risk-based rather than prescriptive. It doesn’t mandate cameras everywhere or continuous staffed monitoring. It expects you to identify your restricted areas, choose monitoring appropriate to each one’s risk, assign clear ownership for maintaining and reviewing those systems, and be able to show that unauthorized access would actually be detected.
That framing should feel familiar. It’s the same shift the industry made from perimeter firewalls to detection and response, applied to buildings. Prevention alone is not a control strategy. You assume the perimeter fails and instrument accordingly.
If you’re running SOC 2 and ISO 27001 together, the good news is the physical controls overlap heavily. Teams pursuing both typically reuse the large majority of their control set across the two frameworks.
The five artifacts you will be asked for
Strip away the framework language and physical access evidence reduces to five things. Build these once and both audits get easier.
1. A scoped facility inventory. Every location inside your audit boundary, the sensitive areas within each, and what protects them. This is the artifact most teams skip, and skipping it means you discover the forgotten colo cage during fieldwork instead of during prep.
2. An access list with authorization trail. Who can enter each restricted area, when access was granted, and who approved it. Not a badge system export showing current state — an export showing state plus the approval that justifies it.
3. Periodic access review records. A dated artifact showing someone reviewed the list against current roles, made removals, and signed off. A screenshot with no date and no reviewer is not evidence.
4. Entry logs for the period. Actual door events, retrievable for the full audit window. This is where teams discover their badge system retains 30 days and the audit period is twelve months.
5. Termination evidence. For a sample of departed employees: badge deactivated, laptop returned, drive wiped, with timestamps. The auditor picks the sample. You do not get to pick your cleanest cases.
On retention: neither framework specifies how long to keep door logs or camera footage. Your policy specifies it, and you’re tested against your policy. Set the number based on your audit window and any regulatory requirements you carry, then verify your systems can actually hold it. Writing “12 months” into a policy while running a system that overwrites at 30 days is an exception you authored yourself.
The gap that produces most findings: offboarding drift
Here is the failure mode I’d bet money on if I audited a random Series B company.
Offboarding is automated in the identity provider. Someone leaves, HRIS triggers deprovisioning, SCIM propagates, Okta access is gone in minutes. Clean, logged, defensible.
The badge system is not in that flow. It’s a separate vendor with a separate admin console, managed by facilities, provisioned by email request. So the badge stays live. Sometimes for months.
The auditor finds this by pulling terminated employees and checking both systems. It’s a trivially easy test and it fails constantly. Worse, it’s a real vulnerability rather than a paperwork problem — a former employee who can still walk into the room with the rack has defeated your entire identity architecture.
The fix is treating physical access as part of the same identity lifecycle you already run:
- Provision building access from the same source of truth as system access, ideally via SCIM
- Include badge deactivation in the offboarding runbook as a checked step with a captured artifact
- Reconcile the two systems on a schedule and log the reconciliation
- Alert on divergence rather than discovering it during an audit
Modern access control platforms expose APIs and identity integrations that make this achievable. Legacy on-prem panels frequently don’t, which is worth knowing before you commit to a control you can’t automate.
Treating physical events like operational events
The teams that handle this well stop treating physical security as a facilities problem and start treating it as a telemetry problem.
Get the logs into your existing stack. Door events, badge denials, and visitor check-ins are structured, timestamped events. If they’re queryable alongside your other logs, evidence collection becomes a query instead of a vendor support ticket, and correlation becomes possible — a production credential used at 3 a.m. is interesting; a production credential used at 3 a.m. with no corresponding badge-in and no VPN session is an incident.
Route the alerts into on-call. A forced door on the network room at 2 a.m. should reach a human the same way a Sev-1 does. If it lands in an inbox someone checks Tuesday morning, A.7.4’s detection requirement is not really being met.
Prefer systems with APIs over systems with dashboards. The distinguishing property of a workable physical security setup, from an engineering perspective, is whether you can query it programmatically. Platforms that unify video, access, and visitor records in one system — Coram’s unified physical security platform is one example, and it’s built to work with existing cameras and door hardware rather than requiring a rip-and-replace — let you pull a single correlated record per event instead of reconciling three exports by hand. That matters less for daily operations and enormously at evidence collection time.
A pre-audit checklist
Run this two months out, not two weeks:
Every in-scope location and restricted area documented
Cloud provider SOC 2 report reviewed, inherited controls documented, complementary user entity controls read and addressed
Badge access lists exported and reconciled against your identity provider
Log retention configured to cover the full audit window — verified, not assumed
Access review process documented, scheduled, and with at least one completed cycle on record
Offboarding runbook includes badge deactivation as an evidenced step
Monitoring in place for restricted areas, with defined ownership for review
Visitor process producing a retrievable log
Device disposal process documented with certificates of destruction
Stated policy matches operating reality — reread it and fix whichever side is wrong
The takeaway
Physical security controls fail audits for the same reason CI/CD controls do: the process exists in people’s heads, the evidence exists nowhere, and nobody discovers the gap until an auditor asks.
The advantage you have as an engineer is that you’ve already solved this problem in a different domain. You know how to make access reviewable, revocable, logged, and alertable. Physical access needs exactly the same treatment. It’s just been sitting outside the boundary of what platform teams considered theirs.
It isn’t anymore. Better to find that out in prep than in fieldwork.
Shubham Bahukhandi leads SEO at Coram AI, an AI-native unified physical security platform that brings video, access control, guest management, and emergency management into one system. He writes about the overlap between physical security operations and modern infrastructure practice.
I’m Rajesh Kumar, a DevOps, SRE, DevSecOps, Cloud, and Platform Engineering expert passionate about sharing practical knowledge, real-world experiences, and industry best practices. I have worked at Cotocus and regularly write about technology, travel, investing, health, product reviews, and digital marketing through my various platforms.
I publish technical articles at DevOps School, travel stories at Holiday Landmark, stock market insights at Stocks Mantra, health and fitness guidance at My Medic Plus, product reviews at TrueReviewNow, and SEO and digital marketing strategies at Wizbrand.
Find Trusted Cardiac Hospitals
Compare heart hospitals by city and services — all in one place.
Explore Hospitals