PS-6: Access Agreements

PS-6: access agreements requirement is easy to “have on paper” and still fail in an assessment. Assessors do not just want to see a policy. They want proof that everyone with system access was presented with the right terms, agreed to them, and that you can show that proof on demand for a given user, system, and timeframe. ¹

Treat PS-6 as a control that binds people to the rules of system access: acceptable use, data handling, monitoring consent, restrictions on privileged actions, remote access conditions, and the consequences of misuse. The agreement is part legal acknowledgement and part security control because it creates clear, auditable expectations and supports disciplinary and incident response actions if access is abused.

This page gives requirement-level implementation guidance you can execute quickly: who owns PS-6, which systems and populations it covers, how to integrate acknowledgement into IAM, HR, and third-party onboarding, and what evidence you must retain to close the “missing implementation evidence” gap. ¹

Regulatory text

Requirement (PS-6): “Develop and document access agreements for organizational systems;” ¹

What the operator must do:
You must produce written access agreement(s) that state the rules for using your systems, and you must keep those agreements documented in a controlled way (approved, versioned, accessible to users and auditors). Then you must connect the agreement to access so it is not optional or informal. ¹

Practical interpretation: PS-6 is not satisfied by an employee handbook reference or a vague “acceptable use policy” sitting in a wiki. Your agreements must be specific enough that a user understands what they can do, what they cannot do, and what monitoring and enforcement apply when they use organizational systems. ¹

Plain-English interpretation (what PS-6 is really asking)

PS-6 asks: “Do you have clear, documented terms for accessing each organizational system, and can you prove that users agreed to them?”

That breaks into three testable components:

1. Documented terms exist for system access (or a defined system grouping with consistent terms).
2. Terms are communicated and acknowledged by the relevant populations before access is granted.
3. Records exist so you can show who agreed to what version, for which system(s), and when.

Who PS-6 applies to

Entities

PS-6 is commonly applied in environments aligned to NIST SP 800-53, including:

• Federal information systems
• Contractor systems handling federal data ²

Operational context (who must sign)

Apply access agreements to any identity that can authenticate to an organizational system, including:

• Workforce members (employees, temps, interns)
• Privileged administrators (highest scrutiny)
• Developers with production access
• Third-party users (MSPs, consultants, support engineers)
• Service and shared accounts, where a human custodian must attest (document how)

Scope by system boundary. If your organization defines multiple authorization boundaries or environments (prod vs non-prod), your agreement language can be shared, but your evidence must still show which systems the agreement governs.

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

Step 1: Assign ownership and define the system scope

• Name a control owner (often Security GRC) and process owners (IAM, HR onboarding, third-party management, Legal/Privacy for monitoring consent).
• Create a system inventory view that groups systems into “agreement tiers,” for example:
  • Tier A: General corporate systems
  • Tier B: Systems processing regulated or federal data
  • Tier C: Privileged/admin access systems
    Keep the grouping rationale short and defensible.

Daydream tip: Track PS-6 in Daydream as a requirement mapped to an owner, procedure, and recurring artifacts so evidence collection is not ad hoc during audits. ¹

Step 2: Draft access agreement content that matches how your systems are used

Your access agreement should be short enough that users will actually read it, but specific enough to enforce. Common clauses that assessors expect to see reflected somewhere in your access terms:

• Authorized use only; no personal or unlawful use
• Prohibition on credential sharing; MFA requirements where applicable
• Data handling expectations (storage locations, encryption expectations, prohibited exports)
• Remote access conditions (device requirements, VPN, secure networks)
• Privileged access rules (no bypassing controls, logging expectations, change control adherence)
• Monitoring and logging notice (coordinate with Privacy/Legal)
• Incident reporting expectations
• Sanctions/disciplinary consequences for misuse

Write one “base” agreement and add addenda for special access (privileged access, production, sensitive datasets, third-party remote support). This prevents “agreement sprawl” that becomes impossible to keep consistent.

Step 3: Establish document control (versioning, approvals, and availability)

Auditors test whether the agreement is controlled like any other compliance document.

• Put the agreement template under document control (policy management tool, GRC repository, or controlled wiki with approvals).
• Record: version, effective date, approver(s), change summary.
• Define when updates trigger re-acknowledgement (material changes, new monitoring conditions, new data handling restrictions).

Step 4: Make acknowledgement a hard gate in your access process

This is where many programs fail. “We told people” is not evidence.

Implement one of these patterns:

• IAM-integrated click-through: Present the agreement at first login or before granting app group membership; capture acceptance in system logs.
• HR onboarding workflow: New hire must sign electronically; HRIS stores acknowledgment; IAM grants access only after HRIS flag is set.
• Ticketing workflow: Access request ticket requires attached acknowledgement or an automated check before fulfillment.
• Third-party onboarding: Contractual requirement plus individual user acknowledgement for named accounts.

Minimum acceptance record fields:

• User identity (unique ID)
• Agreement name and version
• Timestamp
• Method (SSO click-through, e-signature, HR workflow)
• System(s) covered or the tier/grouping covered

Step 5: Handle exceptions without breaking the control

Some access cannot “click accept” (service accounts, emergency access, some API integrations). Document an exception method:

• Human account owner attests the service account is used only for authorized purposes.
• Break-glass accounts: pre-acknowledged by admins, reviewed after use, and tied to incident/change records.

Step 6: Operate the control (recurring checks)

Build an operational cadence:

• Periodic reconciliation: users with access vs users with a recorded acknowledgement for the current agreement version.
• Triggered re-acknowledgement on major updates.
• Offboarding: retain evidence even after the identity is disabled.

Required evidence and artifacts to retain

Keep evidence that proves both design (the agreement exists and is controlled) and operation (people agreed).

Design artifacts

• Access Agreement template(s) and addenda (current and prior versions)
• Approval record (Legal/Privacy/Security signoff where applicable)
• Scope mapping: which systems/tier each agreement applies to
• Procedure: how acknowledgement is collected and enforced (IAM/HR/ticketing)

Operating artifacts

• Acknowledgement logs or e-signature receipts, exportable by user and date range
• Access provisioning records showing the gate (workflow screenshots, configuration export, or ticket samples)
• Exception register for accounts that cannot acknowledge normally, with compensating controls
• Spot-check results from reconciliations and remediation tickets

If you cannot export acknowledgement records, you will struggle in an audit.

Common exam/audit questions and hangups

Expect these:

• “Show me the access agreement for this system boundary and who approved it.”
• “Pick five users with access to System X. Prove they accepted the current agreement version before access was granted.”
• “How do third parties accept the terms? Show evidence for a contractor account.”
• “What happens when the agreement changes? Do you re-collect acceptance?”
• “How do you cover privileged access separately?”

Hangups assessors commonly flag:

• Agreement exists but is not tied to provisioning.
• Agreement covers “network use” but not cloud/SaaS access.
• No clean mapping from agreement version to user acknowledgement records.

Frequent implementation mistakes (and how to avoid them)

1. Mistake: Treating PS-6 as “Acceptable Use Policy” only.
   Fix: Keep AUP, but add explicit “system access terms” language and make acknowledgement a gate.

2. Mistake: One agreement for everything with vague scope.
   Fix: Use a base agreement plus addenda by access type (privileged, production, sensitive data).

3. Mistake: No version control, so you cannot prove what someone agreed to.
   Fix: Version the agreement and store immutable acknowledgement records referencing the version.

4. Mistake: Third parties covered only in the MSA/SOW.
   Fix: Keep contractual language, but require individual user acknowledgement for named accounts where feasible.

5. Mistake: Service accounts ignored.
   Fix: Require custodian attestation plus tight controls on creation, rotation, and monitoring.

Enforcement context and risk implications

No public enforcement cases were provided in the source material for PS-6, so you should treat this primarily as an assessment and incident-readiness risk rather than a control with direct, cited penalty examples in this packet. ¹

Operational risk you are managing:

• Unauthorized use and insider misuse: clear terms support HR and IR actions.
• Audit findings and authorization delays: missing acknowledgement evidence is an easy assessor write-up.
• Third-party access ambiguity: without explicit terms, third-party remote access becomes harder to govern and enforce.

Practical execution plan (30/60/90)

Use these phases as an execution checklist. Adjust sequencing to your change-control constraints.

First 30 days (foundation and scoping)

• Assign PS-6 owner and cross-functional approvers (Security, Legal, Privacy, HR, IAM).
• Build your system-to-agreement scope map (tiers or system list).
• Draft base access agreement and privileged/third-party addenda.
• Decide the acknowledgement capture mechanism (SSO click-through, HRIS e-sign, ticketing).
• Define evidence outputs you must be able to export on demand.

Days 31–60 (implementation and gating)

• Implement the gating control in your chosen workflow (IAM, HR, ticketing).
• Pilot with one high-impact system (SSO apps) and one privileged access path.
• Create the exception method for service accounts and break-glass.
• Write the operating procedure and run a reconciliation test to validate evidence quality.
• Store templates, approvals, and sample acknowledgement exports in Daydream so audit prep is a pull, not a scramble. ¹

Days 61–90 (scale and operationalize)

• Roll out to remaining systems or tiers.
• Train access request approvers and helpdesk on “no acknowledgement, no access.”
• Establish a recurring reconciliation and remediation workflow.
• Add PS-6 evidence collection to your regular control testing or internal audit plan.
• Review agreement language for material changes and define re-acknowledgement triggers.

Frequently Asked Questions

Do we need a separate access agreement for every single system?

Not necessarily. You can group systems under a common agreement if the terms are truly consistent and you can show which systems are covered by that agreement and version. Keep the scope mapping as an artifact. ¹

Can our employee handbook or Acceptable Use Policy satisfy PS-6?

It can contribute, but PS-6 expects an access agreement tied to system access and documented in a way you can prove acknowledgement. If the handbook is not acknowledged in a traceable way for system access, assessors may treat PS-6 as not fully implemented. ¹

How do we handle third-party users who access our systems?

Add contractual terms in the SOW/MSA and also collect individual acknowledgement for named accounts where feasible. At minimum, you need documented terms that apply to third-party access and evidence that those terms were accepted or contractually bound. ¹

What about service accounts that cannot “click accept”?

Document a compensating approach: a human owner/custodian attests to the agreement terms on behalf of the account, and you restrict and monitor the account’s use. Keep the attestation and the account inventory tied together. ¹

Do users need to re-acknowledge after updates?

Require re-acknowledgement for material changes (new monitoring language, new data restrictions, new privileged access rules). Define “material” in your procedure so the trigger is consistent and auditable. ¹

What evidence is most likely to be requested in an audit?

Auditors usually ask for the current agreement, approval/version history, and a sample of user acknowledgement records matched to actual system access grants. If you cannot produce acknowledgement records quickly, PS-6 will be treated as weak even if the document exists. ¹

Footnotes

1. NIST SP 800-53 Rev. 5 OSCAL JSON

2. NIST SP 800-53 Rev. 5