TSC-CC6.4 Guidance

TSC-CC6.4 is one of the SOC 2 Common Criteria that auditors routinely test because physical access failures can bypass strong logical controls. If someone can enter a server room, networking closet, records storage area, or even an office where sensitive devices or documents are left unsecured, they can access systems and data without touching your IAM stack.

This requirement is straightforward, but teams stumble during audits for one reason: they treat “physical security” as a facilities problem and cannot produce end-to-end evidence. Auditors are looking for a managed process that restricts access to facilities and protected information assets, plus proof that the process runs consistently (requests, approvals, logs, reviews, and revocations).

This page translates the tsc-cc6.4 guidance requirement into an execution checklist you can hand to Security, IT, and Facilities. It also calls out common audit hangups, the artifacts you need to retain, and a practical 30/60/90 plan to stand up or harden controls quickly.

Regulatory text

Requirement (excerpt): “The entity restricts physical access to facilities and protected information assets.” ¹

What the operator must do: You need physical access controls that (1) limit who can enter facilities and protected areas, (2) limit who can touch or remove protected information assets, (3) detect and record access activity, and (4) support audit testing with retained evidence across the SOC 2 period. Your controls should cover employees, contractors, visitors, and third parties with onsite presence.

Plain-English interpretation

You must prevent unauthorized people from getting into spaces or handling assets where sensitive data or systems exist. That means:

• Doors, cages, cabinets, and storage areas have “who can access” rules.
• Access is granted only after approval and only for valid business need.
• You can show who entered and when, and you review that activity.
• Access is removed quickly when it should be (termination, role change, contract end).

Who it applies to (entity and operational context)

In scope entities: Any organization undergoing a SOC 2 examination for the Trust Services Criteria ¹.

Operational contexts auditors commonly include in scope:

• Corporate offices that house employees handling customer data or admin access.
• Server rooms, network closets, telecom rooms, and badge-controlled floors.
• Colocation footprints or private cages (even if the building is run by a third party).
• Storage locations for backups, removable media, and paper records.
• Work-from-home and flexible workspace realities, where “protected assets” often become laptops and mobile devices rather than a data center.

Third-party touchpoints: Colocation providers, managed office/building security, maintenance vendors, and cleaning crews can become part of the control story. You still need to manage your side of access governance and evidence, even if a third party runs the building.

What you actually need to do (step-by-step)

1) Define “protected facilities” and “protected information assets”

Create a short scoping statement that an auditor can test:

• Protected facilities/areas: which sites, floors, rooms, cages, and closets contain systems or sensitive operations.
• Protected information assets: server hardware, network devices, end-user devices with access to production/admin tooling, backup media, and sensitive paper records.

Deliverable: an in-scope facilities and assets register (can be a table) mapped to owners.

2) Set access rules (least privilege for doors, not just systems)

Document enforceable rules:

• Which roles can access which areas (e.g., IT Ops can access network closet; Finance can access records room).
• Visitor access rules (escort requirements, check-in/out, badges).
• After-hours access rules and escalation.
• Prohibited behaviors (tailgating, propping doors, sharing badges/keys).

Tip: Write rules in “testable” language (who/what/when), not slogans.

3) Implement access provisioning with approvals and identity binding

Your process should include:

• Request ticket (or workflow) with business justification and scope (which door/area).
• Approval by the area owner (Facilities/Security) plus functional owner (e.g., IT for server room).
• Issuance of badge/key tied to a named individual (no shared badges).
• Time-bounded access for contractors and third parties.

Minimum expectation: you can produce a sample of access grants with documented approvals and issuance records.

4) Monitor physical access activity and keep an audit trail

Collect and retain:

• Badge access logs for protected areas (successful and failed attempts where available).
• Visitor logs (manual or system) with name, company, host, purpose, time in/out, and badge ID.
• Exception logs for incidents like forced doors, alarms, or lost badges/keys.

Operational reality: if your building security system is managed by a third party, contract for log access and retention or establish a pull-and-store routine that you control.

5) Run periodic access reviews (and actually action the results)

Perform a recurring review of:

• Active badge holders with access to protected areas.
• Contractor and third-party access still needed.
• Terminated users or role-changed users removed.

Make it easy to evidence: export the access list, annotate approvals/removals, and retain the before/after state plus the ticket IDs for remediation.

6) Deprovision quickly on termination, role change, or contract end

Define triggers and owners:

• HR termination feed or IT offboarding ticket triggers badge deactivation.
• Contract end dates trigger removal for third-party personnel.
• Lost badge/key triggers immediate deactivation and re-issuance controls.

Auditors will sample offboarding events and trace them to badge revocation evidence.

7) Test effectiveness and document results

SOC 2 requires you to show controls operated effectively over the period. Build a lightweight test plan:

• Sample access grants: verify approval, appropriate scope, and identity binding.
• Sample terminations: verify timely badge disablement.
• Sample visitors: verify sign-in/out and escort rules.
• Validate logs exist and are retained for the period.

If you track this in Daydream, keep the test steps, samples selected, results, and remediation tickets attached to the control for clean audit handoff.

Required evidence and artifacts to retain

Keep evidence in an auditor-ready folder with a clear naming convention by month/quarter:

Policy & procedures

• Physical Access Control Policy / Physical Security Standard
• Visitor Management Procedure
• Offboarding / Deprovisioning Procedure for physical access

Access governance

• Protected areas and asset scope register
• Role-to-area access matrix (who gets what and why)
• Access request/approval tickets (samples across the audit period)
• Badge/key inventory list, including assignment to individuals

Operational logs

• Badge access logs for protected areas (exported or accessible with retention assurance)
• Visitor logs and badge issuance records
• Incident records (lost badges, forced entry alarms, investigations)

Review & monitoring

• Periodic access review evidence (reports, sign-off, remediation actions)
• Exception approvals (temporary access, emergency access)

Testing

• Internal control testing results and remediation tracking

Common exam/audit questions and hangups

Auditors commonly probe these points under CC6.4 ¹:

• “What facilities and areas are in scope, and why?”
• “Show me how a new employee gets access to the server room from request to issuance.”
• “Show me how you remove physical access when someone leaves.”
• “Do you review who has access, and can you show evidence for each review period?”
• “Can you produce badge logs and visitor logs for the audit period?”
• “How do you control third-party onsite access (cleaning crew, contractors, colo techs)?”

Hangups to anticipate:

• Facilities runs badges, Security owns SOC 2, and nobody owns evidence.
• Logs exist, but retention is short or exports are inconsistent.
• Visitor sign-in is informal, or escort rules are unwritten.
• Contractors keep access after the project ends.

Frequent implementation mistakes and how to avoid them

1. No clear definition of “protected information assets.”
   Fix: publish a scoped list (areas + assets) and tie it to your SOC 2 boundary.

2. Shared badges or generic keys.
   Fix: assign access to named individuals; if physical keys are unavoidable, maintain key custody logs and owner accountability.

3. Provisioning without documented approval.
   Fix: require an approval step in the ticketing workflow; keep the ticket ID tied to badge issuance.

4. Access reviews that don’t drive removals.
   Fix: treat reviews as a control with output; capture removals as tickets and keep the “before” and “after” lists.

5. No evidence continuity across the audit period.
   Fix: set a recurring calendar export for logs and reviews; store artifacts in a locked evidence repository.

Enforcement context and risk implications

SOC 2 is an audit framework, not a regulatory enforcement regime, so you should plan around auditor expectations and customer scrutiny rather than fines tied directly to TSC-CC6.4 ¹. The practical risk is still real: physical access failures can lead to unauthorized system access, data exfiltration via removable media, theft of endpoints, and tampering with network equipment. Customers often treat weak physical controls as a sign of broader control immaturity, especially for services that handle sensitive data.

Practical 30/60/90-day execution plan

Days 1–30: Scope, document, and stabilize

• Confirm SOC 2 boundary: sites, protected rooms, and protected assets.
• Draft or refresh physical access and visitor policies; assign owners.
• Inventory badge system capabilities and log retention; close gaps with a manual export process if needed.
• Standardize the access request and approval workflow (ticket templates, required fields).
• Identify all third parties with onsite access; collect rosters and contract points for log access.

Days 31–60: Operationalize governance and reviews

• Build the role-to-area access matrix; enforce it in provisioning.
• Start periodic access reviews for protected areas; document sign-off and actions.
• Implement contractor time-bounding and recurring re-authorization.
• Centralize evidence storage and naming conventions; assign an evidence owner.
• Run a tabletop “lost badge / forced door” response to validate incident handling and documentation.

Days 61–90: Test controls and harden weak points

• Perform internal testing: sample grants, terminations, visitors, and logs.
• Remediate exceptions: remove stale access, fix missing approvals, improve log exports.
• Align third-party building/colo evidence: obtain sample logs, visitor procedures, and access review support.
• In Daydream, map each artifact to the CC6.4 control, then generate an audit-ready evidence pack for the period.

Frequently Asked Questions

Does TSC-CC6.4 apply if we are fully remote?

Usually yes, because “protected information assets” can include laptops and mobile devices with access to sensitive systems. Scope your endpoints and define physical safeguards for remote work (secure storage, device encryption, and incident reporting), then retain evidence that the process runs.

We use a coworking space. What counts as “restricting physical access”?

Restrict access to your own protected assets and any designated secure areas you control (locked cabinets, assigned rooms, device storage). If you rely on coworking controls, document the dependency and keep the relevant third-party evidence and your own procedures.

Our colocation provider controls the building. Are we still responsible?

You remain responsible for governing your personnel access (who is authorized, approvals, reviews, removals) and for obtaining evidence that physical entry to your cage/space is restricted. Contract for logs and access reports, then retain them with your SOC 2 evidence.

What evidence is most likely to fail an audit for CC6.4?

Missing approvals for badge access, inability to produce logs for the full audit period, and access reviews that lack remediation proof are common failures. Fix the workflow first, then lock down evidence retention and review cadence.

How do we handle emergency access to a server room?

Define an emergency access procedure with documented authorization, time-bounded access, and a post-event review. Keep the incident/ticket record, the access log entry, and the approval chain together.

Can we pass with a policy only?

No. Auditors test operating effectiveness, so you need proof the controls ran during the period: requests, approvals, logs, reviews, and deprovisioning evidence ¹.

Related compliance topics

• 2025 SEC Marketing Rule Examination Focus Areas
• Access and identity controls
• Access Control (AC)
• Access control and identity discipline
• Access control management

Footnotes

1. AICPA TSC 2017, 2017