Access Agreements

Access agreements are the “paper control” that makes your technical access controls enforceable, auditable, and repeatable. PS-6 is straightforward, but teams fail it in predictable ways: the agreement exists but isn’t tied to provisioning; the agreement is generic and doesn’t match the system’s risk; signatures are scattered across HR tools, ticketing systems, and inboxes; or the review cadence is implied but never executed.

For FedRAMP Moderate operators (CSPs and agency system owners), treat access agreements as a gating control in your identity lifecycle. You are building a chain of evidence that shows: who requested access, which agreement applied, who signed, when they signed, and that access was only granted after signature. You also need to show that the agreement content is controlled (versioned), periodically refreshed, and updated when your environment changes (new data types, new admin tools, new third-party support model).

This page translates PS-6 into an operator-ready checklist: scope, agreement content, workflow integration, artifacts to retain, exam questions you will get, and a practical execution plan you can assign to HR, IAM, Security, and Legal in the same week.

Regulatory text

Requirement (PS-6): “Develop and document access agreements for organizational systems; review and update the access agreements at an organization-defined frequency; and verify that individuals requiring access to organizational information and systems sign appropriate access agreements prior to being granted access.” ¹

Operator meaning: You must have written access agreements, you must keep them current on a defined schedule, and your provisioning process must verify signature before any access is activated. This is a control design plus an operational workflow requirement, not a one-time policy publication. ¹

Plain-English interpretation

An access agreement is the set of rules a user must accept before using a system or handling organizational information. In practice, it is an “attestation with consequences”: it defines acceptable use, confidentiality expectations, restrictions on sharing, monitoring consent, and the user’s duty to report incidents. PS-6 requires:

• Documented agreement(s) for the systems in scope. ¹
• A defined review cycle (you pick the frequency, but it must be explicit and followed). ¹
• A hard gate before access: signature first, access second, with evidence. ¹

Who it applies to (and typical scope traps)

Applies to:

• Cloud Service Providers (CSPs) operating systems under FedRAMP Moderate authorization expectations. ¹
• Federal agencies operating or managing systems where PS-6 is in scope. ¹

Operational contexts you must cover:

• Workforce users: employees, interns, and temporary staff.
• Non-workforce users: contractors, consultants, third-party support, outsourced administrators, and other third parties with logical access.
• Privileged roles: system administrators, database admins, security admins, CI/CD administrators, and break-glass accounts.
• Remote access and managed devices vs BYOD, if allowed.

Common scope trap: treating PS-6 as “HR paperwork” limited to employees. Examiners and assessors will look for coverage of contractors and third parties, and they will test whether signing is actually enforced before granting access. ¹

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

Use this sequence to implement PS-6 in a way that holds up during assessment.

1) Inventory systems and map agreement types

Create a simple matrix:

• System / environment (production, staging, corporate IT, support tooling).
• User populations (employee, contractor, third party support).
• Access level (standard, privileged, emergency).
• Agreement package that applies.

Output: “Access Agreement Applicability Matrix” owned by Security/GRC.

2) Draft access agreement content that matches real risk

At minimum, ensure your agreement set covers:

• Acceptable use and prohibited actions (credential sharing, bypassing controls).
• Confidentiality and handling rules for organizational information.
• Admin/privileged user obligations (change control adherence, session recording consent where applicable).
• Logging and monitoring notice (user consent/acknowledgment).
• Incident reporting expectations (what to report and to whom).
• Termination/return of access and data upon role change or offboarding.

Keep it readable. If users do not understand it, you will get rubber-stamped signatures with poor deterrence value.

3) Decide the “organization-defined frequency” and document it

PS-6 requires you to define a review/update frequency. Document:

• The review owner (typically GRC with Legal and Security inputs).
• The trigger events (major system changes, new data types, new third-party access model).
• The method of review (version change control, re-attestation decision).

Output: a policy statement and a recurring control activity in your compliance calendar. ¹

4) Build the provisioning gate: no signature, no access

This is the make-or-break step.

Minimum operational requirement:

• Provisioning requests (HR onboarding, IAM tickets, JML workflow, third-party onboarding) must include an automated check or a required evidence field proving the correct agreement version was signed.
• Access activation must be blocked until verification is complete. ¹

Implementation patterns that work:

• SSO/IAM integrated click-through for interactive users, with logging of agreement version, timestamp, identity, and system.
• Ticketing workflow gate for non-interactive/service access (where click-through doesn’t fit), requiring an attached signed PDF or e-sign record ID and reviewer validation before provisioning.
• Privileged access management (PAM) gate where privileged entitlements require a privileged access agreement.

5) Handle exceptions explicitly (and make them painful)

Define narrow exception cases (for example, emergency restore work) and require:

• Time-bound access
• Compensating monitoring
• Post-event signature if truly impossible beforehand, with documented justification and approval trail

If exceptions become common, your process is broken.

6) Re-attestation and updates (review cycle execution)

When you update agreements, decide whether you need re-signing:

• Content-only minor changes: record versioning; re-sign optional based on your risk call.
• Material changes: require re-signing before continued access, especially for privileged users.

Ensure your IAM or ticketing workflows can force re-attestation when required.

Required evidence and artifacts to retain

Assessors look for proof at two levels: control design and operating effectiveness.

Design artifacts

• Access Agreement document(s), with version control and approval history. ¹
• Access Agreement Applicability Matrix (systems x user types x agreement).
• Procedure: “Access Agreement Verification Prior to Access” (the workflow description).
• Defined review frequency statement and ownership. ¹

Operating effectiveness evidence

• Signature/attestation logs: identity, agreement version, timestamp, method (SSO click-through, e-sign, HR system record).
• Provisioning records that show “signed then provisioned” ordering (tickets, IAM audit logs).
• Samples for each population: employee, contractor, third party, privileged user.
• Review evidence: meeting notes, tracked changes, approvals, and release communication for updated agreements.

Tip: store these artifacts in a single control evidence folder keyed by agreement version. Scattered evidence is the fastest path to assessment friction.

Common exam/audit questions and hangups

Expect these:

1. “Show me the agreement and prove it was signed before access was granted.” Provide a user sample with attestation record plus provisioning log timestamps. ¹
2. “What is your review frequency, and show evidence you performed the last review?” If you can’t show the review, the defined frequency does not matter. ¹
3. “Which agreement applies to privileged admins and third-party support?” This tests your applicability matrix and role-based agreement coverage.
4. “What happens when someone refuses to sign?” You need a clear outcome: no access, escalations, and documented closure.
5. “How do you enforce re-attestation after updates?” If you can’t force it, your “update” is mostly theoretical.

Frequent implementation mistakes (and how to avoid them)

Mistake	Why it fails PS-6	Fix
Agreement exists but is not tied to provisioning	You cannot verify signing prior to access. 1	Put signature verification as a required step in IAM/JML workflows and block access until complete.
One generic agreement for all systems	“Appropriate” agreement can be challenged for privileged or sensitive contexts. 1	Use a base agreement plus addenda for privileged access, third-party access, and high-risk systems.
Review cadence is undocumented	PS-6 explicitly requires organization-defined frequency. 1	Document the cadence, assign an owner, and schedule the control activity.
Signatures stored in email or ad hoc PDFs	Evidence becomes incomplete and sampling becomes painful	Centralize e-sign or attestation logs and link them to identity records.
Contractors/third parties handled “outside the process”	High-risk access population lacks proof	Route all third-party onboarding through the same gate, even if sponsored by a business owner.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so treat PS-6 primarily as an assessment and authorization risk. The practical risk is straightforward: without a signed agreement tied to access, you weaken your ability to enforce acceptable use, discipline misuse, and demonstrate controlled onboarding during an incident review. PS-6 gaps also tend to correlate with broader identity governance weaknesses because the same workflow controls (JML, role assignment, privileged access handling) typically break in the same places. ¹

A practical 30/60/90-day execution plan

Use these phases as an execution blueprint. Assign a single accountable owner (often GRC) and named partners (IAM, HR, Legal, Security Operations).

First 30 days (Immediate)

• Gather current acceptable use, confidentiality, and onboarding documents; identify what already functions as an access agreement.
• Build the system/user/role applicability matrix.
• Draft or revise the access agreement set with clear “who must sign what” mapping.
• Define and document review frequency, owners, and triggers. ¹
• Choose the enforcement mechanism (SSO click-through vs e-sign + ticket gate) per population.

Days 31–60 (Near-term)

• Implement the provisioning gate in IAM and/or ticketing: required attestation record before access.
• Stand up centralized evidence capture (attestation logs, e-sign repository, version control).
• Run a pilot with one business unit plus one privileged admin group.
• Write the operating procedure and train service desk/IAM approvers on “no signature, no access.”

Days 61–90 (Operationalize)

• Expand enforcement to all populations, including third parties and privileged roles.
• Run an internal sample test: pick recent onboardings and prove signature-before-access with timestamps.
• Execute the first formal review cycle action (even if no changes) and record evidence. ¹
• Add continuous monitoring: a recurring report for “active users with missing/expired attestation” and a remediation playbook.

Where Daydream fits naturally: teams often struggle to keep the applicability matrix, versioning, and evidence sampling tight across employees and third parties. Daydream can act as the system of record for who must sign which agreement, track artifacts by version, and package audit-ready samples without pulling from five systems.

Frequently Asked Questions

What counts as an “access agreement” for PS-6?

A written agreement (or set of agreements) that users must sign acknowledging rules and responsibilities for accessing organizational systems and information. PS-6 expects the agreement to be documented, reviewed on a defined cadence, and signed before access is granted. ¹

Can an Acceptable Use Policy (AUP) satisfy the requirement?

It can, if it is structured as a signable agreement, mapped to the systems in scope, and enforced as a prerequisite to access. If your AUP is only “published,” it usually fails the “verify signature prior to access” requirement. ¹

Do contractors and other third parties need to sign?

Yes, if they require access to organizational information or systems. Make third-party onboarding follow the same signature verification gate as employees. ¹

How do we prove the agreement was signed before access was granted?

Keep timestamped attestation records and match them to provisioning timestamps in IAM or ticketing logs. Auditors typically sample users and expect to see ordering evidence, not just “signed at some point.” ¹

What does “review and update at an organization-defined frequency” mean in practice?

You must define a review cadence, assign an owner, and keep evidence that the review occurred (even if you decide no changes are needed). Update the agreement when system use, risk, or access populations change. ¹

We updated the agreement; do we need everyone to re-sign?

PS-6 does not prescribe a universal rule. Treat material changes as requiring re-attestation before continued access, and document your decision criteria so the approach is consistent and defensible. ¹

Footnotes

1. NIST Special Publication 800-53 Revision 5