What 03.10.01 physical access authorizations requires in practice
03.10.01 requires you to build and maintain an approved list of the people who may enter the facility where your CUI systems reside, issue access credentials from that list, review the list at a defined frequency, and remove people as soon as they no longer need access. The risk it addresses is simple: anyone physically inside the building, including a former contractor with a working badge, can reach servers, workstations, backup media and network closets that hold CUI. Assessors test this by asking for the authorized access list, the procedures that govern it, and the record of reviews, then checking whether the people on the list match people who should still be there.
The difficulty is that the list drifts. Access is granted in one system, often the badge or facilities platform, while employment status lives in HR and contractor end dates live in procurement or a sponsor's inbox. When one of those sources changes and the others do not, the physical list is wrong without anyone noticing. The review frequency is also an organization-defined parameter: NIST does not set it for you, so you must choose a value, write it into your procedures, and then meet it. Confirm the ODP value with your contracting officer or assessor if a federal agency has specified one, because the nonfederal organization must assign the value when none is given.
Rev. 2 had this as 3.10.1, and NIST's change analysis classifies the move to Rev. 3 as significant, mainly because Rev. 3 expects more detail and foundational tasks such as the procedures themselves. The requirement is distinct from 03.10.02, which is about monitoring and reviewing physical access events to detect incidents, and from 03.10.07, which enforces authorizations at entry and exit points through verification, escorts and logs. In practice, 03.10.01 is the list and its upkeep, and the other two requirements depend on it being right.
Which facilities, people and systems fall under 03.10.01
The access list in 03.10.01 covers only the facility where the CUI system resides, so the first scoping decision is physical. Shared buildings, colocation space, contractors and cloud facilities each change who must appear on the list and who must prove they were reviewed. Settle these boundaries in the system security plan before building the list.
The room or facility holding the system
Start by identifying the exact room, cage, rack or building where the CUI system and its storage physically sit. The access list must cover people with authorized access to that facility, so a vague boundary such as the whole campus leaves gaps or creates an unmanageable list. Record the boundary in the system security plan with a floor plan or site diagram, and confirm that every person who can reach the hardware, including through an adjacent area, is accounted for. Check whether backup media or a disaster recovery site is a second facility that needs its own list.
Shared buildings and tenant space
When the CUI system sits in an office or floor that other companies or departments also use, the access list must show who can cross from common areas into the protected space. Lobby staff, facilities teams and other tenants may not need the list, but their paths to the protected area do. Ask the building owner or landlord for written entry records, badge issuing rules and who controls the key or card system. Where the boundary cannot be controlled, document the compensating measures and the responsibilities agreed with the building operator.
Colocation and data center space
In colocation, the provider controls the building, but your cage or rack is still the facility where your system resides. Confirm with the provider how it issues credentials, whether it keeps a named authorized list for your space, how it removes people, and how often it reviews that list. Ask for the provider's review records and its assurance reports, then decide whether your own list must mirror its list or sit above it. Many organizations keep their own record of who is authorized to request access on their behalf.
Contractors, cleaning and maintenance staff
Contractors, cleaning crews and maintenance vendors often reach the protected space without being employees. Decide whether each category is on the authorized list, is escorted, or is kept out entirely, and write that rule into the procedure. Set an end date for each contractor credential that matches the contract term, and confirm that the vendor's personnel records support the removal of access when the contract ends. Ask vendors to confirm in writing how they track their own staff who hold credentials.
Cloud provider facilities and inherited controls
If the CUI system runs in a cloud or hosted environment, the provider's data center is usually outside your direct control. Your assessment can rely on inherited controls only when the provider's controls are documented and you can confirm they operate as described. Obtain the provider's compliance documentation, identify which physical controls it claims, and confirm that its scope covers the region and facility where your data is stored. Record any gap as a responsibility you retain, and do not assume the provider's list satisfies your own review obligation.
Setting the review frequency
03.10.01 requires the access list to be reviewed at a defined frequency, and that frequency is an organization-defined parameter. NIST does not assign the value. If the federal agency or contract does not set it, your organization must assign one and document it in the system security plan. Ask the contracting officer or prime contractor first, record the answer, and then state the interval you chose with a reason. An assessor will check that the value is defined, so an undefined or unstated frequency can fail the requirement even when reviews take place.
How to build the access list and review cycle step by step
This sequence turns 03.10.01 into a working process: a defined facility boundary, a named owner and approver, an initial list built from authoritative records, a review frequency set as the organization-defined parameter, controlled credential issuance, and removals tied to offboarding. Each step produces a document or record an assessor can examine.
Define the facility boundary for the system
Identify every physical location where the system resides, including data halls, server rooms, colocation cages, offices with workstations that access CUI, and any storage for backups or media. Record the boundary in the system security plan and in a short signed boundary definition. The step is complete when the facility named in the list matches the locations in the system inventory, so nobody with access to a site is missing from the list or appears on it without a reason.
Name the list owner and the approver
Assign one accountable owner for the access list, usually the facilities or security lead, and a separate approver who can authorize access, often the system owner or CISO. Write both roles into the physical protection policy and procedures. The output is a roles entry that shows who maintains the list, who approves additions, and who receives review results. Confirm that the approver is not the same person who grants the credentials where your size allows it.
Build the initial authorized access list
Compile the first list from authoritative sources: HR records for current employees and contractors with a documented need, the badge or access control system export, and the contract register for vendors and maintenance staff. Compare the sources and resolve each mismatch, such as a badge with no HR record. Each entry should carry the person, the facility, the business reason and the approval date. The step closes when the owner signs the list as approved and it is stored under version control.
Set the review frequency as the organization-defined parameter
NIST does not assign the review frequency for 03.10.01, so the organization must set it. Choose an interval that fits the facility risk, record it in the physical protection procedures, and state it in the system security plan. Ask your assessor or the sponsoring agency whether they require a specific value. The output is a documented frequency that an assessor can compare against the review records, because an undefined value leaves the ODP unmet.
Issue facility access credentials under the approved list
Issue badges, keys or codes only to people on the approved list, and record each credential against the list entry with the issue date and the issuer. Credentials for visitors or temporary staff should be linked to a time-bound authorization and an escort rule if your procedures allow visitors. The step is complete when a reconciliation shows that every active credential maps to an approved entry and no credential exists without one.
Run the scheduled review and record decisions
At the frequency you set, the owner compares the approved list against current HR records, contract end dates and badge activity, then asks each sponsor to confirm that access is still needed. Record each decision as keep, change or revoke, with the reviewer and date. Access certification tools such as midPoint can route these decisions to designated reviewers within a set timeframe and keep the audit trail, but the review must still be done and evidenced whichever tool you use.
Wire removals into the offboarding workflow
Connect removal to HR termination, contract end and role change events so that facility access is revoked when access is no longer required, not only at the scheduled review. Where identity is managed centrally, a provisioning connector such as the authentik SCIM provider can deprovision accounts in target applications when a user loses access, but physical credentials usually need a separate revocation step recorded on the list. The output is a removal log that shows the date each credential was deactivated and the trigger that caused it.
How an assessor tests the access list
The examine method looks at documents and records. For 03.10.01, an assessor starts with the physical protection policy and the procedures for physical access authorizations, then checks whether they describe who approves access, how credentials are issued, how often the list is reviewed and how removal works. The assessor then asks for the authorized personnel access list itself and the records of past reviews, because those records show whether the stated process was followed.
- Policy and procedures: the documents must name the approver, the review frequency and the removal steps, not just the intent.
- Authorized access list: each entry should show the person, the access granted, the approver and the date approved.
- Review records: dated sign-offs showing that someone compared the list against current staff and contractors.
- Removal evidence: tickets or logs showing credentials were revoked after a role change or departure.
- Common finding: a list with no approver, or a review record with no date, which cannot show the defined frequency was met.
Before the assessment, confirm the review frequency your organization has set for the ODP and make sure every document uses that same value.
Interviews test whether people understand and perform the process. The assessor talks to the people who approve facility access and to people who hold physical access to the facility where the system resides. Their answers should match the written procedures. Gaps appear when the approver cannot describe the review cycle or when staff do not know how a badge is returned.
- Approvers: they should explain who may approve, what evidence they check and how they confirm the list is current.
- Personnel with access: they should describe how they received their access and what happens when they leave or change roles.
- Review timing: if the stated frequency is annual but approvers describe reviews only when someone complains, the assessor will record a finding.
- Ownership: someone must be named as responsible for the list, including backup coverage during absence.
- Common finding: leavers still listed because the facilities team and HR do not share a notification.
Prepare interviewees by reviewing the procedure with them so their answers match the documents the assessor has already read.
The test method checks that the processes and mechanisms work in practice. For 03.10.01, the assessor follows a real grant and a real revocation through the system. This is where a paper process meets the badge system, the identity directory or the sign-in log. Tools that manage identities can help produce this evidence, but the organization must confirm which of its own systems actually enforce facility access.
- Grant trace: pick a recent new hire and follow the request, approval and credential issuance to the access list.
- Revocation trace: pick a recent leaver and confirm the credential was disabled and the entry was removed.
- Access certification: in tools such as midPoint, designated reviewers decide within a set timeframe whether to keep, change or revoke each access item, which can produce review evidence.
- Directory-driven removal: in tools such as authentik, the SCIM provider deprovisions users from a target application when access is lost, which helps when the target system is the one that controls facility access. Confirm this covers badge or door systems in your environment.
- Common finding: the process exists, but the revocation step depends on a manual ticket that nobody closes.
Before testing, confirm which system is the source of truth for facility access and make sure its logs can be exported for the assessor.
SP 800-171A Rev. 3 turns the requirement into determination statements, which are the specific points an assessor must find satisfied. For 03.10.01 there are six determination statements that cover the list, the credentials, the review and the removal, plus one more that checks the organization-defined parameter (ODP) is defined. The ODP for this requirement is the frequency at which the access list is reviewed. NIST does not assign that value, so a nonfederal organization must set it, and an assessor will check that it is written down.
- Six determination statements: they cover authorizing the list, issuing credentials, reviewing at the defined frequency and removing access when no longer needed.
- The ODP determination: a separate statement checks that a review frequency is defined and documented.
- Consistency: the value in the policy, the procedure and the review records must match.
- Federal guidance: if a contracting agency specifies a value, use it. Confirm this in the contract or the program's requirements.
- Common finding: a policy that says reviews happen regularly, with no defined frequency, which fails the ODP check.
Ask your assessor or the contracting agency which frequency they expect before you set one, and check the current SP 800-171A Rev. 3 text for the exact wording.
Which evidence passes the 03.10.01 test
An assessor testing 03.10.01 will examine written policy, the access list itself, and the records showing that the list is reviewed and cleaned up. Each card below is one artifact, and together they show that access was authorized, credentialed, checked at the defined frequency and removed when it was no longer needed.
Approved facility access list
This is the core artifact: a list of every individual authorized to enter the facility where the system resides, with a named owner for the list and the approval date and approver for each entry. Record the access purpose and the level of access granted, so the list can be matched against actual entries. Export a dated copy on a fixed schedule so the list at any past point can be shown, not only the current version. Confirm with your assessor which list format they accept.
Badge and credential issuance records
Issuance records show that each facility credential, such as a badge, key or PIN, was issued to a person on the approved list and only after approval. Log the credential identifier, the recipient, the issue date and the authorizing approver. An assessor will compare these records against the access list to find credentials with no matching approval. Confirm with your facilities team how lost and replaced credentials are recorded, because those events also need traceable approval.
Signed access review records
Each periodic review of the list should produce a signed record showing which reviewer checked it, the date, and the decision for each entry: keep, change or remove. A review that confirms every entry without showing any reasoning is weak evidence. Identity platforms such as midPoint can run access certification campaigns in which designated reviewers decide within a set timeframe, and their decision history can serve as this record. Confirm the review frequency with your own policy before the first review cycle.
Removal tickets tied to offboarding
Removal is the step most often missing from evidence. For each individual removed from the list, keep a ticket that records the trigger, such as a role change or departure, the date access was revoked and the person who confirmed it. Link these tickets to HR offboarding so that a departure cannot close without a matching facility removal. An assessor will often sample recent leavers and check whether their access was actually removed on time. Confirm your target timing with your own policy.
Written review frequency
03.10.01 includes an organization-defined parameter for how often the access list is reviewed, so the frequency must be assigned and written down. Put the value in the physical protection procedures and the system security plan, and name the role responsible for running each review. An assessor checks that the documented frequency matches what the review records show. If the review records show a different cadence than the written one, the gap is a finding even if the reviews themselves were sound.
Physical protection policy and procedures
The policy states why facility access is controlled and who is accountable for it. The procedures explain the steps: how access is requested, approved, issued, reviewed and removed. Both should name owners and show a revision history with approval dates. An assessor examines these first to understand what the other artifacts are meant to prove. Keep a dated copy of each version so that the procedure in force during any past review can be shown.
What meeting 03.10.01 costs in money and effort
This table breaks the cost of keeping an approved facility access list into components, showing who is paid for each, whether it is one-time or recurring, and what drives it up or down. Use it to structure a quote request, since no price or duration is published for this requirement.
| Cost component | Who is paid or who does the work | One-time or recurring | What drives the cost |
|---|---|---|---|
| Badge or physical access system licenses | Access control vendor or reseller, or none if the system is self-hosted open source | Usually recurring if commercial; open-source platforms remove license spend but not hosting | Number of facilities, number of doors and readers, and whether the vendor charges per credential |
| Building the initial access list | Facility or security staff, with HR and system owners confirming who needs access | One-time | Number of people with physical access, number of facilities and how many records exist today |
| Ongoing list maintenance and credential issuance | Facility security staff and HR | Recurring | Hiring and role change volume, contractor turnover and visitor or temporary badge use |
| Periodic access list review | Designated reviewers, often facility managers and system owners | Recurring, once per review cycle | The review frequency you set as the 03.10.01 parameter, and the number of entries each reviewer must check |
| Removal work during offboarding | HR, facility security and system administrators | Recurring, tied to each departure | Speed of HR notification, number of physical sites, and whether removal is automated from the identity source |
| HR and identity integration | Internal IT or an implementation partner building connectors | One-time build, then recurring upkeep | Number of identity sources, quality of HR data and whether a directory such as FreeIPA or an identity provider is already in place |
| External consulting and readiness support | Implementation partner preparing evidence, or a consultant reviewing the list | Usually one-time for setup, optional recurring for support | Fixed-scope written agreement versus retainer, and how many facilities are in scope |
| Assessor time | Independent assessor or the federal agency reviewing evidence | Recurring with each assessment cycle | Number of facilities sampled, quality of records and how easily evidence can be produced |
Who owns the access list, who helps and who audits it
Your organization owns the requirement. Your security or facilities function must decide who belongs on the access list for the facility where the system resides, approve each entry, issue credentials, and remove people when their need ends. No outside party can make those decisions for you, and the access list is only credible if it reflects choices your staff can explain. The 03.10.01 requirement also asks you to set the review frequency yourself when no federal agency has specified it, because the organization-defined parameter must have a value.
- Approving the list: Named managers or the security office approve each individual and record who approved them and when.
- Issuing and retrieving credentials: Badges, keys and codes are issued against the approved list and collected on departure.
- Running reviews: Staff compare the list against current roles and remove or re-justify entries at the frequency you defined.
- Setting the parameter: Document the review frequency in your physical protection procedures, or confirm the value with the agency that holds your contract.
- Keeping the record: Retain approvals, review sign-offs and removal tickets as the evidence an assessor will examine.
Before relying on this tab, confirm who in your organization holds each of these duties, in writing.
An implementation partner such as DeployOpen can prepare the technical support for the access list, but it does not approve access or decide who enters the facility. Under a fixed-scope agreement, the partner can connect your directory to the systems that carry the access workflow, build the review and removal workflow your staff will operate, and export evidence in a form an assessor can read. The scope and deliverables should be agreed in writing before work starts.
- Directory integration: Connect an identity source such as FreeIPA to the access records so that group membership and facility authorizations are traceable.
- Review workflow: Configure a certification campaign in a tool such as midPoint so that designated reviewers decide to keep, change or revoke each item within a set timeframe.
- Automated deprovisioning: Where the scope includes it, set up provisioning from authentik over SCIM 2.0 so that removals propagate to target applications.
- Evidence exports: Produce review logs, approval histories and removal records on a schedule your team chooses.
- Documentation handover: Deliver runbooks so your own staff can operate the workflow after the engagement ends.
Ask the partner to state in the statement of work which tasks it does not perform, including approving access and certifying compliance.
The independent assessor examines your evidence, interviews the people involved and tests whether the mechanisms work. SP 800-171A Rev. 3 gives the assessor determination statements for 03.10.01 that cover the policy, the access list, the reviews and the controls behind them. The assessor decides whether each determination is met and issues the assessment result. Neither your team nor an implementation partner can issue that result.
- Examine: The assessor reads the physical protection policy, the access authorization procedures and the approved access list.
- Interview: The assessor speaks with people who hold access responsibilities and with personnel who use the facility.
- Test: The assessor checks that the processes and mechanisms actually grant, review and remove access as documented.
- Parameter check: The assessor confirms the review frequency is defined, since a missing value fails a separate determination.
- Independence: A partner that built the workflow should not also be the assessor for the same scope, and the assessor should not design the controls it tests.
Before engaging an assessor, confirm with the contracting agency which assessment it accepts and how the result must be reported.
Where 03.10.01 programs usually fall short
Most access list failures are not technical. They come from lists with no owner, no review cadence and no link to the people processes that create and end access. The cards below cover the gaps assessors most often find when they test 03.10.01 Physical access authorizations, with a closing action for each.
No defined review frequency
03.10.01 has one organization-defined parameter: the frequency at which the access list is reviewed. NIST does not set that value, so if the organization has not defined it, the requirement is not complete. Assessors check that a number exists, that it is written down in the policy or procedure, and that the reviews actually happened at that interval. Confirm the value with your own policy owner and record it in the system security plan.
Lists not tied to HR and badges
The access list is often built by hand from memory, so it drifts from the people who actually hold credentials. Each entry should trace to an HR start date, a sponsoring manager and a badge or key that was issued. Ask for a sample of ten badge holders and check that each one appears on the approved list with a documented approval.
Removals that wait weeks
Access that stays active after a departure is one of the most visible findings in physical access testing. The gap usually sits between the HR termination notice and the facility team, which may learn about it days or weeks later. Set a written removal trigger tied to the offboarding ticket, and test it by comparing terminated employees against active badge records at the last review.
Reviews with no recorded decisions
A review that produces no written outcome is hard to defend. Assessors look for evidence that a designated reviewer looked at each entry and decided to keep, change or revoke it, with the date and the reviewer's name. Access certification tooling such as midPoint can record those decisions with a timeframe for reviewers, which gives the review a durable record rather than an email thread.
Visitors and contractors left out
Contractors, vendors and temporary staff often receive escorted or short-term access that never reaches the authorized list. Their credentials may stay active after the work ends. Confirm whether the list covers every person with unescorted access, whether each contractor has a named sponsor and an end date, and whether the list is reconciled against contractor badge records.
List with no owner
A spreadsheet on a shared drive usually has no accountable owner, no change history and no protection against edits. When the person who maintained it leaves, the list goes stale. Name one accountable role for the list, store it in a controlled system with an audit trail, and document who may change it and how changes are approved.
Questions buyers ask about 03.10.01
How much effort does maintaining a physical access list take?
The effort is mostly recurring administration rather than a one-time build. Building the list is a single pass over people who already hold facility access, but keeping it accurate depends on how often people join, change roles and leave, and on how many entry points and credential types the facility uses. The requirement also expects a defined review frequency, and each review consumes time from the access owner and an approver. The organization sets that frequency, and NIST leaves the value to be defined through an organization-defined parameter. Ask any provider to break the effort into one-time setup and recurring review, and to state which hours fall on your staff versus theirs.
Does 03.10.01 apply to a cloud-only company with no data center?
It applies to the facility where the system resides, so the question is where your CUI-handling systems physically run and where people work with them. A company that runs everything in a public cloud still has offices, and those offices or the staff who administer the cloud environment may fall within the scope the assessor defines. The cloud provider's physical controls are generally covered through that provider's own attestations, but you still need to show how your staff and any on-premises equipment are controlled. Confirm the boundary with your contracting officer or assessor before you write the system security plan.
Can an implementation partner build the access review workflow for us?
Yes, a partner can plan, configure and document the workflow, but the organization still owns the control. The review decisions, the approval of who gets access and the review frequency must be made and signed off by your people. A partner can connect an identity source to an access certification tool, set up reminders and reviewer assignments, and produce records showing each review was completed. DeployOpen plans and implements self-hosted open-source platforms in your own infrastructure and prepares evidence for assessments, but it does not issue assessment reports or certificates. An independent assessor makes that judgment.
What does the access list need from facilities and HR staff?
The list depends on two feeds that usually sit outside IT. Facilities or physical security must confirm who holds badges, keys or other credentials and must deactivate them when access ends. HR must notify the access owner when someone joins, transfers or leaves, so removals happen promptly. Plan a short written procedure that names the owner of each feed, the trigger for a change and the record kept. Without that handoff, the directory can show a person as removed while a badge still works, which is the gap an assessor is most likely to test.
Does the Rev. 2 requirement for this control differ from Rev. 3?
The core expectation is similar, but Rev. 3 is more detailed. Under Rev. 2, the matching requirement is 3.10.1, which covers maintaining a list of authorized individuals, issuing credentials and reviewing the list. NIST's change analysis classifies the Rev. 3 change for this area as significant, because it adds more detail and foundational tasks. Rev. 3 also adds an organization-defined review frequency that you must set. CMMC Level 2 still assesses the Rev. 2 wording as PE.L2-3.10.1, and it is worth 5 points under 32 CFR 170.24, so DoD contractors should confirm which version their contract currently requires.
Will an assessor accept an open-source directory as evidence?
An assessor evaluates the evidence and the process around it, not the license of the product that produced it. An open-source directory such as FreeIPA can hold the users and groups that define who is authorized, and its access control and delegated administration help show who can change the list. The assessor will still expect an approved list, documented review records, dated removals and proof that the list reflects physical reality. Tools like midPoint can record access certification decisions, and authentik's SCIM provider can deprovision users from target applications. Confirm each capability in your own environment and test that the records export in a form an assessor can read.
How does access revocation tie into the rest of the access list process?
Revocation is where most lists fail, so treat removal as a timed workflow rather than an occasional clean-up. When a person's access ends, the directory change should remove their application access through provisioning, while facilities deactivates physical credentials. Automated deprovisioning in identity tools covers digital access only. Physical credentials still need a manual or badge-system step, and that step needs a record. Ask your provider to show a test removal that produces a log entry on both the digital and physical side.
How DeployOpen prepares access evidence for 03.10.01
DeployOpen is a Chainscore Labs company that plans, implements and documents self-hosted open-source platforms inside the client's own infrastructure, and it prepares the systems and evidence an assessment will examine for 03.10.01. Scope, deliverables and timelines are agreed in writing before work starts, so the organization knows in advance which access lists, review records and identity configurations will be produced and who owns each one. DeployOpen does not issue assessment results, attestations or certifications. An independent assessor decides whether the requirement is met, and the organization owns its controls, its facility and its physical access decisions.
In practice, the preparation work for this requirement sits in two places. The first is the authorized access list for the facility where the system resides, which the organization must approve and keep current. Where that list is held in a self-hosted identity platform, DeployOpen can help configure groups that map to facility authorizations and document who approves additions. The second is the removal step. For example, an open-source identity provider such as authentik can use its SCIM provider to deprovision users from target applications when they lose access, which supports the removal evidence an assessor will ask for. This is illustrative only: the physical access list itself is usually maintained by facilities or security staff, so the integration must be confirmed against the organization's own process and the platform's current documentation.
The review frequency is the parameter the organization must set for 03.10.01, and it is the part most often left undocumented. Before work begins, the reader should confirm the review interval with their security and facilities leads, decide who signs each review, and check whether an access certification tool such as midPoint is in scope for recording keep, change or revoke decisions. Ask any implementation partner to state in the written scope which evidence artifacts it will produce, which remain the organization's responsibility, and which items fall outside the engagement entirely.

