PS-6 Access agreements: requirements and evidence

What PS-6 access agreements require and why assessors ask for signed copies

If your organization is facing an audit, a customer contract or a new system launch that asks for signed access agreements, PS-6 is the control being tested. In short, PS-6 requires you to develop, document and review access agreements at a defined frequency, and to have each individual sign them before access is granted and again when the agreement is updated or at a defined interval. The organization decides what the agreements say, how often they are reviewed and what happens when someone refuses to sign. The control exists because users who never accepted the rules of use or their confidentiality obligations are hard to hold accountable after an incident. An assessor will therefore look for two things: a current, approved agreement, and proof that the people using the system signed the version in force at the time they accessed it.

The difficulty is rarely writing the agreement. Nondisclosure, acceptable use and conflict-of-interest agreements usually sit in different places: HR owns onboarding paperwork, legal owns contractor templates and IT owns the system login banner. When those copies drift apart, nobody can answer which version a given person accepted, or whether a contractor signed anything before receiving credentials. Confirm with each owner where the current signed records live, which version each population signed, and whether the system enforces acceptance before access or only records it afterward. The signed record must tie a named individual to a specific document version and date, and that link is what most assessors ask to see first.

PS-6 is the only PS control in the SP 800-53B privacy baseline, so the requirement applies even where the impact level of a system is otherwise low. That makes it a practical starting point for organizations that handle personal information. The organization owns the agreement text, the review cycle, the signing process and the retention of signed records. An implementation partner can help configure systems and document the workflow, but only an independent assessor can test whether the control operates as written. Before any assessment, decide who approves each agreement version, define the review frequency in your own policy and check that a sample of recent hires and contractors can produce their signed copies on request.

Which users, systems and third parties PS-6 reaches, including the privacy baseline

PS-6 scope is set by the baseline you select, the populations you name in your agreements and the systems those agreements cover. The cards below separate the decisions that change the work from the ones that only change the paperwork, so you can settle scope before drafting any templates.

Every impact level plus the privacy baseline

SP 800-53B allocates PS-6 to the low, moderate and high baselines, and the privacy baseline includes it too. An organization that processes PII therefore inherits PS-6 even if its system is categorized as low impact. Check whether your system's privacy baseline status is set before you assume the requirement is optional. Confirm the baseline selection in your system security and privacy plan before scoping agreements.

Employees, contractors and administrators

Most organizations start with employees, then find that contractors, temporary staff and system administrators hold access that was never covered by the same agreement. Administrators with privileged access often need a separate agreement that addresses their elevated responsibilities. List every population with logical or physical access to in-scope systems, and record which agreement each population signs.

Privileged and vendor support users

Vendor support engineers and privileged service accounts used by people are a frequent gap. A vendor's own acceptable use terms do not replace your agreement with the individuals who reach your systems. Decide whether vendor staff sign your agreement directly or whether the vendor contract binds them, and document that choice with the vendor.

Per system or organization-wide agreements

An organization-wide nondisclosure or acceptable use agreement covers everyone once, which simplifies re-signature after updates. A per-system agreement fits systems with distinct rules, such as those handling classified or regulated data. Whichever model you choose, a re-signature trigger must reach every person who holds access, so keep a current list of who signed which version.

External personnel under PS-7

PS-7 covers external providers such as contractors and service bureaus. Where PS-7 applies, the provider's staff may need to sign your access agreements in addition to meeting the provider's own obligations. Write the provider's signing duty into the contract and confirm which party keeps the signed copies and produces them on request.

Enhancements are not in the baseline

The Release 5.2.0 enhancements for PS-6 are not allocated to any SP 800-53B baseline, so the base control sets the scope. Work from the base requirement and your own risk decisions, and do not add enhancement obligations to the baseline unless your organization or contract requires them. Confirm with your assessor whether any additional requirement applies to your authorization boundary.

How an assessor tests PS-6 access agreements

This table maps the four SP 800-53A determination statements for PS-6 to the examine, interview and test methods an assessor uses, the evidence each method requests and the findings that commonly appear. Read it as a checklist of what to prepare before an assessment begins.

Determination statement focus	Methods and assessment objects	Evidence requested	Typical interview subjects	Common findings
Access agreements are developed and documented	Examine: personnel security procedures, procedures addressing access agreements for organizational information and systems, access control policy	Current access agreement templates (nondisclosure, acceptable use, conflict of interest), the procedures that describe who drafts them, and the access control policy that references them	Personnel security staff who own the procedures and the policy owner	Agreement types exist but procedures do not say which systems or roles require them, or the procedures predate the current templates
Access agreements are reviewed at a defined frequency	Examine and interview: procedures and access control policy for the review cycle; personnel with personnel security responsibilities	Documented review schedule, review meeting or approval records, version history showing when each agreement was last reviewed and by whom	Personnel security staff responsible for scheduling and approving reviews	Review frequency is stated in policy but reviews are overdue, or no record shows who approved the last review
Individuals sign agreements before access is granted	Interview: organizational personnel who have signed access agreements; test: processes for granting access against signature status	Signed agreements linked to each account, access request tickets showing the signature date precedes the grant date, and sample account lists reconciled to signed records	Users who recently received access, and the staff who provision accounts	Accounts exist with no signed agreement on file, or agreements are signed after access was already granted
Individuals re-sign after updates or at a defined frequency	Test: organizational processes for reviewing, updating and re-signing access agreements; interview: personnel who have re-signed	Re-signature logs, change records showing which agreement revision triggered re-signing, and reminder or expiry reports for periodic re-signature	Users who signed a prior revision, and the staff who track agreement versions	Agreement text changed but no re-signature was requested, or periodic re-signature reminders were never sent to some user groups

How to put PS-6 access agreements in place, step by step

This sequence turns PS-6 into working practice: agreement types and signers are defined, review and re-signature rules are set, the documents are approved, access is gated on signature, and reviews have an owner. Each step leaves a record an assessor can examine.

Define agreement types and the roles that sign them
Start by listing the access agreements your systems need, such as nondisclosure, acceptable use and conflict-of-interest agreements, and state what each one covers. Map each agreement to the roles that must sign it, including employees, contractors, and any other individuals who receive access. The output is a scoping table that links every agreement type to its signer population and the systems it governs. You know this step is done when every role with system access appears in at least one row.
Set review frequency and re-signature triggers
PS-6 leaves the review frequency and the conditions for re-signature to the organization, so these values must be defined explicitly. Decide how often each agreement is reviewed and which events force a new signature, such as a material change to the agreement text or a change in the individual's role. Record these as your organization-defined parameters and confirm them with the control owner. The output is a parameter record that assessors can compare against the control's stated requirements.
Draft and approve the agreements with legal and HR
Write each agreement in plain language that matches the scope defined in the first step, then route the drafts to legal counsel and HR for review. Legal confirms enforceability and jurisdictional requirements, while HR confirms how signatures fit into onboarding and offboarding. Keep version numbers and approval dates on every document. The output is an approved set of agreements with a version history, which is the document an assessor examines first.
Gate account provisioning on signed agreements
Connect the signing step to the access provisioning workflow so that no account or privilege is granted until the required agreement is recorded as signed. This can be a workflow rule in your identity or ticketing system, or a manual checkpoint if you do not automate provisioning, but it must be enforced and not left to individual judgment. Test the gate with a sample request from a person who has not signed. The output is a provisioning gate with a documented test result showing the request was blocked.
Run the first signing campaign and record it
Issue the approved agreements to all in-scope individuals, collect signatures, and log the date, agreement version and signer for each. Follow up on anyone who has not signed and decide in advance how access is handled for non-signers. Store the signed records in a location that keeps them retrievable and protected. The output is a complete signature record for the population, with exceptions documented and tracked to closure.
Schedule reviews and assign a named owner
Assign one named owner for the agreement set, along with the reviewers for legal and HR input, and put the review dates and re-signature triggers on a calendar. At each review, confirm that the agreement text is still accurate, that signatures are current, and that any changes triggered re-signature. Record the outcome of each review as a dated entry. The output is a review log tied to a named owner, which shows the review process is operating and not only documented.

Evidence that passes PS-6 and how to keep it current between audits

An assessor testing PS-6 looks for a chain of records: the agreement text in force, who signed which version and when, proof that reviews happened on schedule, and proof that signature came before access. The cards below cover the artifacts that form that chain and how self-hosted tools can hold them. Neither wiki nor documentation tooling records signatures on its own, so the organization must confirm where signing happens.

Approved agreement texts with versions

Keep each nondisclosure, acceptable use and conflict-of-interest agreement as a numbered, approved document with an owner, an effective date and a version identifier. Assessors examine these texts to confirm the agreements cover the organizational systems in scope and the access they grant. Check that the approved text is the one users actually see at signing, and that retired versions remain retrievable for the period you must prove what people agreed to.

Signed-agreement register

Maintain a register that links each user account to the agreement and version they signed and the date of signature. This is the record an assessor uses to check that every person with access holds a current signature. Reconcile the register against the active user list at each review, since a register that lags behind provisioning shows gaps that a sample test will find.

Review and update records

Record each review of the access agreements against the frequency your organization defined, including who reviewed them, what changed and why. PS-6 requires agreements to be reviewed at a defined frequency, so the review log must show the cadence was followed, not only that a review once happened. Keep meeting minutes or approval comments with the version history so the reasoning behind each revision is visible.

Provisioning check before access

Show that access was granted only after the signature was recorded. Pair the signed-agreement register with the account creation timestamp for a sample of new users, and confirm that no production or system access was enabled earlier. This check depends on your identity or ticketing workflow, so confirm which system gates access and whether it blocks provisioning until the signature exists.

Re-signature records after updates

When an agreement changes, or when the defined re-signing interval passes, record which users re-signed, when, and against which version. Track users who have not re-signed and the action taken, such as suspending access until they do. Assessors test this process directly, so the records should show both completed re-signatures and how outstanding ones were handled.

Editor and reader permissions

Control who can change agreement texts separately from who can read them. In BookStack, abilities come from assigned roles, and permissions can be overridden per role at the shelf, book, chapter or page level, so the agreements can sit in a restricted book where only the policy owner and approvers can edit. Confirm the permission settings in your own instance and export them as evidence of who could alter an approved text.

What meeting PS-6 access agreements costs in money and effort

This table breaks the PS-6 effort into cost components, showing who does the work, whether the cost is one-time or recurring, what pushes it up and how to keep it down. NIST does not estimate compliance costs and no figures are supplied for this topic, so use the table to scope a written quote rather than to budget.

Cost component	One-time or recurring	What drives it up	How to keep it down
Legal drafting and review of agreements	One-time per agreement type, then recurring at each revision	Number of agreement types, number of user groups needing different terms, changes in contract or employment law	Consolidate to a small set of agreements (for example, one nondisclosure and acceptable use agreement with role-specific annexes) and reuse approved language
HR and records time for collecting signatures	Recurring at onboarding, after each update and at any re-signature cycle	Manual or paper signing, large populations, contractors who sit outside HR systems	Use e-signature within your existing HR workflow and tie signing to onboarding tasks so it happens once per trigger
Engineering time to gate account provisioning on signature	One-time build, then recurring maintenance	Number of systems and identity sources, custom provisioning scripts, separate tools for each application	Gate provisioning in one identity workflow or central access request process rather than system by system
Tooling or licenses for the agreement register and document store	Recurring license or hosting, plus one-time setup	Commercial suites priced per user, number of separate repositories, need for audit trail features	Use a single register and a self-hosted open-source wiki or document platform in your own infrastructure. Confirm the license terms (for example, LGPL-2.1-or-later or MIT) with counsel before deployment
Evidence upkeep through review cycles and re-signature campaigns	Recurring at the review frequency you define and at each update	Review frequency chosen, frequency of agreement updates, poor version history, many owners	Set a review frequency that matches your change rate, assign one owner per agreement and keep version history so reviews are quick to document
Independent assessment or auditor sampling	Recurring at each assessment cycle	Number of user populations sampled, number of agreement versions in scope, gaps in signed records	Keep signed records complete and retrievable so sampling does not turn into a search. Ask the assessor how many samples they expect
Implementation partner preparation work	One-time, optionally followed by retainer support	Scope of systems and populations, existing documentation maturity, number of integrations	Agree a fixed scope in writing before work starts, and separate the one-time build from any ongoing support

Who owns PS-6 access agreements: in-house, partner and auditor

Your organization owns PS-6 in full. The wording of each access agreement, the roles that must sign it, the review frequency and the rule that blocks access until signature all remain internal decisions. Assessors will ask who approved the wording, who set the review cycle and who is accountable when someone refuses to sign, and the answers must come from named staff rather than from a vendor.

Agreement content: Legal, HR and security leads agree the nondisclosure, acceptable use and conflict-of-interest wording that applies to your systems, and legal counsel signs off before publication.
Review frequency: You set the defined review frequency for access agreements, document it in your personnel security procedures and keep a dated record of each review.
Signing decisions: HR and system owners decide which roles must sign before access, who may grant a documented exception and how that exception expires.
Access rules: Access managers enforce that no account is provisioned until a current signed agreement is on file, and that re-signature is requested when the agreement changes.
HR accountability: A named HR owner handles noncompliance, linking refusals or missed re-signatures to your sanctions process under PS-8.

Check that each named owner can produce a current approval, a dated review record and a sample of signed agreements for their area.

Where PS-6 programs usually fall short and how to close each gap

Most PS-6 findings are not about missing paper. They come from agreements that cannot be tied to a specific version, access that is granted before signature, and review or re-signature steps that leave no record. Each card below names one gap, the evidence an assessor will ask for, and the fix to put in place before the assessment.

Signatures not tied to a version

The organization has an acceptable use or nondisclosure agreement, but the signed record does not show which text the person accepted. When the agreement changes, an assessor cannot tell whether a signature covers the current wording. Store each agreement version with a unique identifier and effective date, and record that identifier on every signature. Pull a sample of signed records and confirm each one points to the version in force on the signing date.

Access granted before signature

Provisioning in the directory or application runs on a ticket from the hiring manager, while the agreement is signed later in an HR portal, so accounts can exist for days without a signed agreement. Make signature a gating step: the identity system should not activate an account until the agreement record exists. Ask for a sample of new accounts and compare each account creation date with its signature date.

Contractors and vendor users missed

Agreements are usually run through HR, so contractors, consultants, managed service staff and vendor support accounts often fall outside the process. These users may hold more privileged access than employees. Build a list of every non-employee account from the identity provider and from application-level accounts, and confirm each one has a signed agreement with the right terms for its role.

Reviews scheduled but not evidenced

The policy sets a review frequency, yet no dated review record, reviewer name or change log exists. An assessor testing the review process will look for proof that the agreement was examined and either approved or revised. Keep a review log that records the date, the reviewer, the decision and any resulting version. Use page history or a document management system so that the log cannot be edited silently.

Updates that do not trigger re-signature

When legal or security staff revise an agreement, the new text often goes live without a notice to users or a re-signature request. Under PS-6, individuals must re-sign when the agreement is updated or at a defined frequency. Define which changes are material, route each material change to a re-signature campaign, and block access for users who have not re-signed by the deadline. Keep the campaign records as evidence.

Privacy obligations missing from agreement text

The privacy baseline applies PS-6 to every system that handles PII, but many agreements only cover confidentiality and acceptable use. Users who handle personal data also need to acknowledge the purposes, handling rules and reporting duties that apply to that data. Map each PII-handling role to the privacy terms it must accept, add those terms to the agreement, and check the sample agreements for those clauses during the review.

Questions buyers and practitioners ask about PS-6 access agreements

How much effort does PS-6 access agreements take to implement?

The effort depends mostly on how many distinct agreements the organization needs, how many people sign them, and how many systems they gate. PS-6 asks for agreements to be developed, documented and reviewed at a defined frequency, with signatures collected before access is granted and again when agreements change. A single nondisclosure agreement for a small workforce is a modest task. Separate acceptable use, conflict-of-interest and system-specific rules for contractors, administrators and privileged users add drafting, legal review and tracking work. Recurring effort comes from review cycles, re-signature campaigns after each update, and keeping signature records linked to account provisioning. Ask any provider to break its quote into drafting, review, workflow setup and recurring records.

How long does a first PS-6 implementation usually take?

No duration is quoted here because the timeline depends on the written scope: the number of agreement types, the review path through legal and HR, and how much of the signature workflow must be built. Most engagements are fixed-scope, so scope, deliverables and timelines are agreed in writing before work starts. Organizations that already have signed agreements and a review cycle usually need less time to document and evidence PS-6 than those starting from nothing. Ask for a timeline tied to specific deliverables, and ask which steps depend on your legal and HR approvals.

What does PS-6 need from HR, legal and IT?

Each function owns a different part of the control. HR typically owns the workforce population, the onboarding and offboarding triggers, and the sign-off process for employees and contractors. Legal owns the wording of nondisclosure, acceptable use and conflict-of-interest agreements, and approves changes at each review. IT owns the link between a signed agreement and access: accounts, group membership and privileged roles should not be granted until the record exists, and re-signature prompts should follow version changes. The organization remains accountable for its controls, so these owners should agree on the review frequency and the evidence before implementation begins.

Can an internal team implement PS-6 without an outside partner?

Yes, an internal team can implement PS-6 if it has HR and legal capacity to draft and review agreements, and if IT can enforce signature before access. Many organizations do this in-house. An implementation partner can help where the internal team lacks time, system integration skills or assessment experience. DeployOpen prepares systems, controls and evidence for assessments, but the organization owns its controls and decides which agreements are required. Independent auditors and certification bodies issue any reports or certificates. Test your internal plan against the assessment procedure before deciding whether to bring in outside help.

Can a self-hosted tool hold PS-6 evidence, and what can it not do?

A self-hosted wiki or documentation platform can hold the agreement texts, review records and approval history. XWiki keeps every change to a page under version control, recording what changed, when and by whom, and lets users compare versions and roll back. BookStack assigns user abilities through roles, with permissions that can be overridden per role at the shelf, book, chapter or page level, which helps restrict who can edit agreement content. These tools cannot collect signatures on their own, prove that an account was blocked until signature, or replace legal review. Confirm with the vendor and your own environment whether signature capture, identity linkage and audit exports meet your assessor's needs. Plan a separate record for the signing event itself.

Does the privacy baseline change the PS-6 work?

PS-6 is the only personnel security control allocated to the privacy baseline in SP 800-53B, so it applies regardless of system impact level. In practice, the agreements should address how personnel handle personally identifiable information, and the review cycle should reflect privacy obligations. The control itself does not change between baselines: the same requirement to develop, review and obtain signatures applies. The privacy baseline adds scope, not a different procedure. Confirm with your privacy office which agreement content it expects. SP 800-53B does not allocate any enhancement of PS-6 to a baseline, so no enhancement applies by default.

What does the auditor need for PS-6 and what does DeployOpen prepare?

An assessor applying SP 800-53A examines personnel security procedures and access control policy, interviews personnel with security responsibilities and staff who have signed or re-signed agreements, and tests the processes for reviewing, updating and re-signing agreements. The organization supplies the documents, the signature records and the review history. DeployOpen prepares the systems, workflows, documentation and evidence so these can be produced on request, within a written scope. DeployOpen does not issue audit reports, attestations or certifications. Only an independent assessor or certification body does that. Ask your assessor which sample of signature records they will test before the engagement is scoped.

How DeployOpen prepares PS-6 access agreements and evidence

DeployOpen plans, implements and documents self-hosted open-source platforms inside the client's own infrastructure, and prepares the systems and records that show PS-6 access agreements are developed, signed and reviewed. The organization owns its agreements and its personnel security decisions, and only an independent assessor issues assessment results.

How we scope

Confirm which systems and user populations the access agreements must cover, including employees, contractors and privileged users.
Agree in writing which agreement types are in scope, such as nondisclosure, acceptable use and conflict-of-interest agreements.
Record the review frequency and re-signature triggers that the organization sets for PS-6, with its policy owners named.

How we build

Configure the wiki or documentation platform to hold versioned agreement templates, review records and approval history.
Set role-based permissions so policy owners can edit agreements while signatories and auditors have read-only access.
Build a signed-acknowledgment record that ties each agreement version to the individual, date and system access granted.

How we hand over

Deliver the agreement library, version history settings, permission model and runbook for signature and re-signature steps.
Document the evidence map that links each PS-6 determination statement to the artifacts an assessor will examine and interview.
Provide written handover of open items, with the organization confirming which findings and sign-offs remain its responsibility.

How we support

Offer ongoing support and upgrades as a retainer, including updates to agreement templates when policy or NIST releases change.
Review version history and signature records with the organization's compliance lead before each internal or external assessment.
Ask the organization to confirm its assessor's expectations early, since only the independent assessor determines whether PS-6 is met.