CC6.4 Physical access restrictions: SOC 2 requirements

What SOC 2 CC6.4 requires for physical access

CC6.4 asks the organization to limit physical access to data center facilities, backup media storage and other sensitive locations to authorized personnel. For a compliance lead, the task is to show an auditor that the people who can walk into those places are the people the organization has deliberately approved, and that the approval list stays current. The risk behind the criterion is straightforward: anyone who can physically reach a server, a storage array or a tape or disk holding customer data can often bypass logical controls entirely. A stolen drive or an unescorted visitor in a server room can expose data that no password policy protects. For cloud-hosted SaaS companies, this criterion is harder to explain than it first appears. Most production facilities belong to a cloud provider, so the organization does not hold the badges, cameras or cage keys itself. The usual approach is to scope the cloud provider's physical controls as a subservice organization and rely on its SOC report, while the organization keeps the parts it does control, such as corporate offices, laptops, any on-premises network closets and backup media it handles. Confirm the cloud provider's current SOC report coverage and the complementary user entity controls it lists, because those are the controls you must perform yourself. The criterion's points of focus cover four activities: creating or modifying physical access, removing it, recovering physical devices and reviewing physical access. Treat them as characteristics that help you design and evaluate controls, not as a checklist that each control must satisfy one by one. In practice, the auditor will look for a request and approval step for badges and keys, a removal step tied to offboarding, a process for retrieving badges and devices, and a periodic review of who holds access to each restricted location.

Which facilities, assets and third parties fall under CC6.4

CC6.4 applies only to the physical locations and media inside the system boundary defined in the system description. The decisions below determine which facilities, devices and vendors the auditor will test, and what the scoping document must record for each.

Owned and leased offices and server rooms

Any office or closet that houses production servers, network gear or systems that store protected information is in scope. Office spaces with only laptops and no in-scope systems are usually not. Confirm which rooms hold in-scope equipment, who holds keys or badges to each, and whether the lease or building manager controls access outside your team. The scoping document should list each room, its equipment, the access method and the named owner of that access.

Colocated and cloud data centers

When you rent cabinets in a colocation facility, the facility's badge, visitor and camera controls usually sit with the provider. Your own controls then cover who you authorize to enter and how you keep that list current. In a cloud deployment, the provider's physical controls are typically documented in its SOC report, which you review and map to CC6.4 rather than test directly. Record the provider, the report period and which physical controls you rely on.

Backup media and off-site storage

Backup tapes, removable drives and replicated storage sent to a vault or another site hold the same data as production and fall under this criterion. Many teams overlook them because they sit in a box or a third party's warehouse. Confirm who can request retrieval, how transport is logged, how custody is signed over and whether the storage vendor's access controls are reviewed. The scoping document should name each storage location and custody chain.

Laptops and removable media with protected data

Employee laptops, phones and USB drives that hold or can reach protected information are physical assets that can leave the premises. Their physical protection includes screen locks, storage of devices when unattended and recovery of devices at offboarding. Decide which device classes are in scope, whether disk encryption is enforced, and how lost or unreturned devices are recorded. The scoping document should state the device population and the recovery process.

Vendors whose physical controls you rely on

Couriers, shredding firms, facilities managers and co-location providers may hold or control physical access on your behalf. Where you depend on their controls, the auditor will expect you to identify them as subservice organizations and address their controls through their reports or your own monitoring. Confirm which vendors are relied on, obtain their current assurance reports and note any complementary controls you must perform yourself. The scoping document should list each vendor and the specific control relied on.

How an assessor tests physical access restrictions

This table lists each area an assessor typically examines under CC6.4, what the assessor does, the evidence requested and the findings that usually appear. Read it as a preparation checklist: for each row, confirm you can produce the evidence for the full examination period, not only on the day fieldwork starts. For Type 2 reports, most of these tests are sample-based, so consistent records matter more than a single clean snapshot.

Test area	What the assessor does	Evidence requested	Common findings
Access list for data centers and backup media locations	Compares the list of people with physical access against job roles and the authorization approvals on file	Current access list, approval records for sampled grants, and the list of locations in scope	Access lists that include former staff or contractors, and approvals dated after access was granted
Provisioning of badges and keys	Samples new grants and confirms each was approved by an authorized owner before the badge or key was issued	Access request tickets, approval emails or workflow records, and badge issuance logs for the sampled people	Approvals missing or given after issuance, and requests that do not state the location or access level
Removal of badges and keys	Samples separations and checks that physical access was removed within the timing the organization set in its own procedure	Termination or offboarding records, badge deactivation logs and key return forms	Badges still active after the separation date, or no record of when access was removed
Periodic review of physical access	Confirms the review happened at the frequency the organization defined, and that reviewers removed access that was no longer needed	Signed or logged review results, the list reviewed, and the follow-up actions taken	Reviews not performed in some periods, reviews with no evidence of who approved them, or no changes recorded
Recovery of devices and keys at separation	Checks that physical devices, keys and tokens were returned or recovered for sampled leavers	Asset return checklists, device inventory updates and key custody records	Laptops, tokens or keys marked as issued but never shown as returned
Cloud facility controls and subservice carve-out	Confirms which physical controls belong to the cloud provider, obtains its SOC report and checks it covers the period and locations used	Provider SOC report, bridge letter if the gap is not covered, complementary user entity control list and the organization's own review of the provider report	No documented review of the provider report, carve-out not described in the system description, or user controls not implemented
Sampling in a Type 2 examination	Selects samples across the observation period and tests each sample for both design and operation	Population lists and the records behind each sampled item, so the assessor can trace each one	Incomplete populations, which lead the assessor to expand samples or report an exception

How to implement physical access restrictions step by step

This sequence takes a team from an undefined physical footprint to a documented, reviewed set of access controls for CC6.4. Each step produces a record an auditor can sample, and the order keeps the scope decisions ahead of the access decisions that depend on them.

Define protected locations and assets in scope
Start by listing every physical location that houses protected information assets: data center facilities, server rooms, office spaces where production hardware or sensitive paper records sit, and backup media storage. For each location, record the assets it holds and whether the organization operates the space or a subservice organization does. Owners of the system description should review the list so it matches the boundary written in the system description. The closing artifact is a location register with an owner, asset types and a scope decision for each entry, approved by the control owner.
Inventory who holds physical access
For each location in the register, pull the current list of people and service accounts that can enter it. Capture the mechanism behind each entry, such as badge credentials, keys, combination codes, biometric enrollment or escort-only status, and note whether the holder is an employee, contractor or vendor. Compare the list against the HR roster and contractor list to find holders who no longer need access. The closing artifact is a baseline access inventory per location, signed by the facilities owner and dated so later reviews can be compared against it.
Set the approval and removal workflow
Write the procedure for granting physical access and for removing it, then tie both to a request form and a named approver for each location. Requests should state the business reason, the locations needed and the expected duration of access. Removal should be triggered by termination, role change or contract end, with the owner confirming that credentials, keys and codes were returned or disabled. The closing artifact is a written procedure plus a set of sample approval and removal records, which an auditor can use to test the design of the control.
Configure physical access logging and visitor handling
Turn on logging for badge readers, door controllers and any monitored entry points, and confirm that logs are retained and can be retrieved for a given door and date range. Set up a visitor process that records name, organization, host, time in and out, and escort assignment, and that requires a visitor badge or log entry before access. Test the logs by walking a sample entry through the system and confirming it appears with the right identity. The closing artifact is a logging configuration summary, a visitor log template and a test record showing the trail works end to end.
Confirm subservice organization coverage for cloud facilities
For facilities run by a cloud provider or colocation operator, obtain the provider's current SOC report and review the sections covering physical access, along with any complementary subservice organization controls the report lists. Map each physical control in your register to either an internal control or a provider control, and note any gap that falls to the organization. Confirm the provider report period overlaps your own examination period, and ask your auditor how they plan to treat carved-out controls. The closing artifact is a subservice coverage matrix showing which party owns each physical control.
Run the first access review and record results
Compare the baseline inventory against the approval records and the logs for the review period. Flag any holder without a matching approval, any holder whose role no longer requires access, and any log entry without a visitor record where one is expected. Each flagged item needs a documented decision: revoke, approve with a reason, or escalate. Ask the approver to sign off on the outcome and keep the exception list with its remediation dates. The closing artifact is a signed review report with the reviewer's name, the scope, the population sampled and the actions taken, which is the record an auditor will request for the review point of focus.

Evidence that satisfies CC6.4 and how to keep it current

CC6.4 is tested by sampling records, so the evidence must show a complete population of physical access events, not a handful of examples prepared for the audit. The cards below cover the artifacts an auditor usually asks for and how often each one goes stale between audits. For cloud-hosted systems, the provider's current SOC report sits alongside them in the vendor file.

Register of protected locations

This is the list of facilities, server rooms, cages and backup media storage that hold protected information assets, with the owner of each location and the controls that restrict entry. It defines the boundary every other access record is tested against, so an omitted room is a gap no sample will reveal. Check that the register matches current facilities after every move, new colocation contract or decommissioned site. Confirm that cloud-hosted assets are recorded with the provider's facility controls referenced rather than left blank.

Access list with owners and approval dates

The access list shows each person with physical access to a protected location, the business reason, the approving owner and the date that approval was given. Auditors sample from this list to confirm that each grant traces back to an authorized need. It goes stale quickly when contractors, vendors or temporary staff are added without an expiry date. Review it on a schedule your policy sets, and remove names whose role no longer requires entry before the review is signed.

Access request and approval records

Each request for physical access should show who asked, what location and level of access was requested, who approved it and when. These tickets prove that access was granted through a defined process rather than by informal arrangement. The common failure is approval after the fact, or a verbal approval that never reached the ticketing system. Confirm that every entry on the access list has a matching request and approval, and that approvers are the owners named in the register.

Badge and key issuance and revocation logs

Badge, key card and physical key logs record when credentials were issued, to whom, and when they were revoked or returned. Revocation timestamps matter most, because a badge still active after a departure is the finding auditors look for first. Export the badge system's event history for the full observation period so the population is complete. Reconcile the log against the leaver list each month, since badge systems often keep working for accounts that HR has already closed.

Separation and device recovery checklist

When someone leaves or a device holding protected data is retired, this checklist shows that physical credentials were collected, equipment was returned and media was handed over for disposal. It links the people process to the physical one and gives the auditor a single record per separation. Keep one checklist for each departure, signed by the manager and the security or facilities owner. Check that each checklist cross-references the badge revocation timestamp and the asset return record.

Periodic access review reports

A periodic access review compares the access list against current roles and records the reviewer's decision for each person. The reviewer's signature and date show that someone independent of the grant actually examined the population. Reviews fail when they are signed without changes or when the reviewer cannot see the badge logs. Confirm the review covers every protected location in the register, that removals are tracked to completion, and that the reviewer is named in the policy as the accountable owner.

What meeting CC6.4 costs in money and effort

This table compares the main cost components of meeting CC6.4, who is paid for each, whether it is one-time or recurring, and what changes its size. No fee figures are given because none are supplied for this topic, so use the questions in the last column to build a written quote before work starts.

Cost component	One-time or recurring	What drives it up or down	What to ask for in a quote
Internal staff time to build the location register and approval workflow	One-time, with upkeep	Number of facilities, cage and rack locations, and backup media sites; fewer locations and a single approval path reduce effort	Named owner for the register, the list of locations in scope, and who approves each access type
Badge, key or access control system licenses	Recurring, often per site or per user	Vendor pricing model, number of doors and readers, and whether an existing system can be reused; self-hosted open-source access tooling may reduce license spend but needs its own hardening and support	Itemized license terms, renewal dates, and whether the quote covers hardware, installation and support separately
Data center or colocation contract review	One-time at contract signing, then at renewal	Whether the provider's SOC report covers physical controls and whether a subservice organization carve-out applies; a longer review follows a bespoke contract	Written confirmation of which physical controls the provider covers, and how the organization obtains the provider's report
Periodic physical access review effort	Recurring, at the review interval the organization sets	Number of people with physical access, turnover, and how many sites exist; automated badge exports shorten the review	Review frequency, the report format used as evidence, and who signs off each review
Joiner and leaver physical access processing	Recurring, tied to staffing changes	Staff turnover and how quickly badges and keys are recovered and revoked	Turnaround commitments in writing, and the record kept when a device or key is recovered
Auditor sampling and walkthrough time	Recurring, once per examination period	Number of sampled access changes, sites in scope, and how well evidence is organized before fieldwork	A written engagement letter that states the sample approach, the period covered and the evidence list
External review of physical controls	Optional, one-time or periodic	Whether the organization wants an independent physical security assessment beyond the auditor's testing; scope and site count drive it	Written scope, named assessor credentials, deliverables and the date the report will be ready
Implementation partner preparation work	One-time, with optional retainer for upkeep	Number of systems to document, existing evidence quality, and whether monitoring is needed between audits	Fixed-scope written deliverables and timelines before work starts; DeployOpen issues a quote from that scope

Who owns, who implements and who attests to physical access controls

Your organization owns CC6.4. Management decides which facilities and protected information assets are in scope, who may enter them, and how that access is granted, reviewed and removed. Those decisions belong to named people in your company, and an auditor will ask who made them and when. If your systems run in a cloud provider's data center, you still own the rules for access to your own cage, cabinets, backup media and any office where sensitive equipment sits, even when the provider runs its own physical controls.

Access policy ownership: A named owner, usually the security or IT lead, approves the physical access policy and the list of restricted locations.
Approvals: Someone accountable approves each new badge, key or remote-hands request for a restricted area, and the approval is recorded before access is granted.
Periodic reviews: Management reviews who holds physical access on a set schedule, removes stale entries and keeps the review record.
Removal and recovery: Your team ensures access is revoked when people leave or change roles, and that badges, keys and devices are recovered.
Vendor oversight: You review the physical controls of colocation or cloud providers through their SOC reports and confirm the carve-out in your system description.

Before engaging anyone, confirm that each of these owners has a written role and that someone in-house can explain the controls to an auditor.

Where organizations usually fall short on CC6.4

Most CC6.4 findings trace back to the same few weaknesses: nobody knows where protected data sits physically, access lists drift, and departing staff keep the means to enter. Each card below names one gap, how to close it, and the record an assessor will ask to see.

No inventory of physical locations

Teams often restrict access to the main office and the hosting provider's facility without listing every other place protected information lives. Backup media in a vault, a server cabinet in a branch office, or printed records in a storage room can fall outside the access model entirely. Close the gap by building a register of facilities and media storage locations that hold in-scope data, with an owner for each. Evidence is the signed register, reviewed on a set schedule, that matches the system description.

Physical access lists never reviewed

Badge and key holder lists are usually granted once and left alone, so former contractors and role changers keep entry they no longer need. An assessor testing CC6.4 will look for a periodic review in which a manager confirms each person still needs access to each restricted area. Close the gap by assigning a named reviewer per location and removing access that is not confirmed. Evidence is the dated review record, the list before and after review, and the removal tickets.

Leavers keep badges and keys

Access is often removed from the directory or identity system while physical badges, door codes and keys stay in the hands of the person who left. This is the physical side of the joiner and leaver process. Close the gap by adding badge and key return to the offboarding checklist, with deactivation tied to the employment end date. Evidence is the leaver record showing the device was returned and the credential was disabled on the same day it was due.

Relying on the cloud provider's physical scope

A provider's SOC report can cover data center physical controls, yet many teams never check whether those controls apply to the regions, facilities and services they actually use. Where part of CC6.4 is carved out to a subservice organization, the complementary controls the organization must run still fall to it. Close the gap by reading the provider's report scope, mapping which physical controls it covers, and documenting the gaps in your own responsibilities. Evidence is the scope mapping and the complementary user entity control record.

Unlogged visitor access to backup media

Contractors, auditors and facilities staff sometimes enter a room holding backup media without a sign-in record or an escort. Because backups often hold the full data set, this access carries the same risk as production access. Close the gap by requiring a visitor log, an escort rule and a time-bound approval for every entry to backup storage. Evidence is the visitor log for the review period and the approvals that authorized each visit.

No evidence of device recovery

Laptops, drives and tokens issued to staff or vendors are rarely tracked back to the person and the location when the relationship ends. Without recovery records, the organization cannot show that physical assets holding protected information left its control. Close the gap by linking each issued device to an owner in the asset register and recording its return at offboarding. Evidence is the asset register with return dates and the recovery exceptions followed up with a named owner.

Questions buyers ask about CC6.4 cost, effort and outside help

How much work does CC6.4 add to a SOC 2 examination?

CC6.4 adds one criterion to the common criteria that every SOC 2 covers, so the direct workload is a defined set of physical access controls plus the evidence for them. The criterion asks you to limit physical access to facilities and protected information assets, such as data center facilities and backup media storage, to authorized personnel. Most of the cost sits in the operating records (access requests, removals, device recovery and periodic reviews) rather than in building new controls. If your production systems sit entirely with a cloud provider, much of the physical work may fall to that provider's report. Confirm with your CPA firm which portions of CC6.4 you must test yourself and which you can carry through the provider's SOC report.

How long does it take to build CC6.4 controls, and what slows it down?

The time depends less on the controls themselves and more on how much of your physical footprint you own. A company with no office server room and a cloud-only production environment has a short list of items to define. A company running its own racks, offices with restricted areas or backup tapes in an off-site vault has more locations, more people and more records to set up before the observation period starts. Delays usually come from unclear ownership of badges and keys, missing removal records for leavers and no agreed schedule for access reviews. Ask your auditor which dates they need evidence for, because a Type 2 report tests operation across a period, not a single moment.

Can a company hosted in the cloud rely on its provider for physical controls?

Often yes, in part. The TSC allows that part of a criterion may be met by a subservice organization's controls, and a cloud provider's SOC report can cover its data center physical access. You still own the portion that concerns your own locations, such as office badges, any on-premises equipment and backup media you hold yourself. Your auditor will decide how to treat the provider through the carve-out or inclusive method, and will expect complementary user entity controls on your side. Obtain the provider's current SOC report, read its scope and exceptions, and confirm with your auditor that its coverage matches the locations you use.

What does CC6.4 need from our own staff?

Your staff must run the processes that the auditor will sample. In practice that means someone approves physical access for each person before it is granted, someone removes it when a person leaves or changes role, someone recovers badges, keys and devices, and someone reviews the list of people with access at a set interval. Facilities, HR and IT usually share these steps, so the control owner should be named and the handoffs written down. Staff also need to be able to produce the records quickly. Confirm with your auditor how many samples they will select and which records they will request, so the owners know what to keep.

Can a small team handle CC6.4 in-house without outside help?

A small team can usually run CC6.4 in-house if its physical footprint is small and the records are kept consistently. The main risks are an informal process that depends on one person, access granted through verbal requests, and no evidence when someone leaves. A small team should decide who owns each step, record every grant and removal, and schedule a review that someone other than the approver performs. Outside help is most useful when the team has no one with time to run the process, or when the first examination needs a readiness check. Ask your CPA firm whether they expect a dry run before the observation period begins.

What can an implementation partner take off our hands for CC6.4?

A partner such as DeployOpen can prepare the technical side of the evidence and the systems that produce it. In a self-hosted or hybrid environment, that can include setting up access logging, documenting the access process, configuring the records your team keeps, and preparing evidence packs for the auditor. DeployOpen plans, implements, documents and supports self-hosted open-source platforms inside your own infrastructure, and most engagements are fixed-scope with the scope agreed in writing before work starts. The company itself is not involved in issuing a report. The organization still owns its controls, and the work is priced from the written scope rather than from a published rate.

How does auditor independence limit what a partner can do for CC6.4?

An auditor must stay independent of the organization it examines, so the partner that prepares your evidence cannot be the party that tests or certifies it. Only an independent CPA firm issues a SOC 2 report. A partner may help you design, document and collect controls, but it should not make management decisions, sign the management assertion, or write the description of the system on your behalf. Ask your auditor before signing any engagement which activities they consider acceptable for a preparer, and get that position in writing. The rules that apply to your engagement are set by the auditor and the AICPA standards, so treat their answer as the governing one.

How DeployOpen prepares physical access evidence for SOC 2

DeployOpen works on CC6.4 Physical access restrictions as an implementation partner inside your own infrastructure, preparing the physical access controls, records and evidence your organization owns. Your organization keeps ownership of its controls, and only an independent CPA firm issues the SOC 2 report.

How we scope

Agree in writing which facilities, data centers, cages and backup media storage locations fall inside the examination.
Identify which physical access controls your organization operates and which a cloud or colocation provider's SOC report covers.
Define the physical access evidence the CPA firm will request, such as access lists, reviews and badge records.

How we build

Configure access request, approval and removal workflows so each change to physical access leaves a dated record.
Set up recurring physical access reviews with named reviewers, scheduled reports and documented follow-up on exceptions.
Document how lost or returned badges and devices are recovered, and test that the procedure runs as written.

How we hand over

Deliver a control matrix mapping each CC6.4 point of focus to the owner, procedure and evidence location.
Provide a dated evidence package with access lists, review records and removal records ready for auditor sampling.
Document which controls rely on subservice organizations so your team can request the right carve-out or complementary controls.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after the fixed-scope work closes.
Retainer support can keep access reviews running between audits and update evidence when facilities or providers change.
Ask your CPA firm to confirm the evidence format and sampling approach before the examination period begins.