Access Management¶

This document establishes the organization's policy for managing accounts and access to the system, and the procedures by which GRC-ITSM executes that policy. Its governing rule is short: every account action is a User Access Request.

Creating an account, changing what an account can reach, disabling it, terminating it, resetting an authenticator, granting or removing privileged access, and executing what a recertification review decided are all the same record type, differing only by category. This document covers that record's lifecycle categories, the approval process that fires on it, the evidence each decision writes, the self-registration front door, the separately-run recertification and account compliance reviews, and the identity-provider hardening the client owns.

It implements the Identity and Access Management Key Security Indicator for automating account management (KSI-IAM-AAM) on the platform side, with NIST 800-53 AC-2 and AC-6 lineage and CMMC Level 1 and Level 2 access-control traceability. The remaining KSI-IAM indicators are client-owned identity-provider configuration and are stated as such below.

Related documents own the adjacent disciplines. The recurring account recertification and the privileged and non-privileged account compliance reviews are recurring tasks in the Continuous Monitoring and Reporting Policy and Procedures. Agency and customer access to certification data, including the denial clock, is the Certification Data Sharing and Trust Center Policy and Procedures. Suspicious activity that reaches an account is handled as an Alert or Incident under the Incident Response Policy and Procedures; the account action that follows returns here as a User Access Request.

Download the KB article (Markdown)

Framework applicability¶

FedRAMP 20x classes differ in validation depth, not in the procedure itself: Class B should evidence each KSI with at least one automated method, Class C must use at least two, and Class D at least four. Class A follows its alternative-framework path.

Policy¶

• P-1. Every account action is a User Access Request. Every creation, modification, disablement, termination, authenticator reset, privileged-access grant or removal, and recertification-driven change is raised and executed as a User Access Request ticket. This holds for staff and agent accounts and for portal users alike. There is no second path, no informal path, and no administrative shortcut: an account state that changed without a User Access Request is a finding, not an exception.
• P-2. The category carries the lifecycle stage. A single ticket type spans the whole account lifecycle, and the ticket's category says which stage this action is. The category set is fixed (see the Organization-defined values table), so the request population is countable by stage without parsing prose.
• P-3. Approval fires immediately on the ticket. The approval process runs on the User Access Request as soon as it is raised. There are no workflow stages to advance through, no queue to be promoted out of, and no intermediate states between raise and decision. This is deliberately unlike the staged workflows on Vulnerability Deviations, Change Requests, and Incidents.
• P-4. Approval is by the CAB, never by the assigned agent. The Approver - User Access Requests role grants membership to the User Access Request Approvers CAB, who approve requests. The Agent Assignment - User Access Requests role assigns a tracking owner. Tracking ownership is not approval authority.
• P-5. Every decision is an auditable ticket. The request, its category, its target account, its justification, the approver, the decision, and the decision time are all held on one record. The ticket is the audit record for that account action, and it is retained.
• P-6. Every decision generates evidence without anyone assembling it. The deployed User Access Request validation generator writes dated machine validation evidence on each access decision. Evidence is a byproduct of operating the process, not a separate collection exercise.
• P-7. Self-registration creates an account, not access. A self-registered portal account exists and may be associated with a client by email-domain match, but it reaches nothing until an approved User Access Request grants access.
• P-8. Least privilege is the default posture for a grant. A request grants the access the justification supports and no more. Privileged access is requested, approved, and removed under its own category so privileged grants are separable from ordinary ones in every count and report.
• P-9. Recertification runs separately, and its outcomes come back through this process. The account recertification and the privileged and non-privileged account compliance reviews are recurring compliance tasks, not steps inside a User Access Request. They are wired to this process by P-1 rather than by an integration: any account change a review decides is executed as a User Access Request, under the recertification category.
• P-10. No approver approves their own request. Separation of the requesting and approving parties is a property of the CAB decision, not a discretionary courtesy.
• P-11. Identity-provider hardening is the client's to configure and evidence. Just-in-time authorization, least-privilege enforcement in the directory, passwordless and phishing-resistant authentication, non-user authentication, and automated response to suspicious activity are configured in the client's identity provider. This platform governs the access decision and its record; it does not configure the client's directory. See Client responsibilities.
• P-12. The procedure reviews itself. The ISSO reviews this document for effectiveness on the cadence in the Organization-defined values table, together with the recertification and account-review outcomes, and when frameworks, the system, or lessons learned warrant.

Organization-defined values¶

Roles and responsibilities¶

• Requester. Raises the User Access Request with its category, its target account, and the justification for the access sought. Anyone may raise a request, including on behalf of another person.
• User Access Request Approvers CAB. The Approver - User Access Requests role grants membership to the User Access Request Approvers CAB, who approve requests. Approval is always by the CAB, never by the assigned agent. The CAB decides on the justification and records the decision on the ticket. No approver approves their own request.
• Assigned agent (User Access Requests). Each User Access Request is assigned a tracking owner automatically via the Agent Assignment - User Access Requests role. Assignment confers tracking ownership, not approval authority. The owner carries the ticket to a decision and to the executed account state.
• Implementers (system and directory administrators). Execute the approved account action in the identity provider and record completion on the ticket. Implementers do not decide access.
• Continuous Monitoring team. Executes the recurring account recertification and the account compliance reviews as recurring tasks, and raises a User Access Request for every change those reviews decide.
• ISSO. Owns the access decisions in aggregate: which categories are in use, whether privileged grants are justified, and whether the review outcomes are being executed. Reviews this document on the cadence in the Organization-defined values table.
• System Owner. Accountable for the access posture of the system. Approves exceptions, in writing.

The User Access Request¶

One ticket type spans the account lifecycle. The category says which stage the action belongs to, and the approval process runs on the ticket itself.

flowchart TD
    A["Account action needed<br/>(staff, agent, or portal user)"] --> B["User Access Request raised<br/>with lifecycle category,<br/>target account, justification"]
    B --> C["Approval process fires immediately<br/>on the request"]
    C --> D["User Access Request Approvers CAB decides"]
    D -->|Approved| E["Action executed in the identity provider;<br/>completion recorded on the ticket"]
    D -->|Denied| F["Denial recorded on the ticket"]
    E --> G["Dated machine validation evidence<br/>written automatically"]
    F --> G

The lifecycle categories¶

Onboarding, offboarding, and privileged access¶

The three cases people ask about are combinations of the categories above, not separate processes.

The front door: self-registration¶

The portal login page offers Create New User Account. A self-registered account is associated with a client when its email domain matches one; otherwise it is held on the Unknown site, unassociated.

Registration is not access. In either case the account can reach nothing until an approved User Access Request grants it something. Self-registration therefore removes an administrative step from account creation without moving the access decision: the decision is still a CAB decision on a ticket. The full agency and customer access model, including the 5-business-day FedRAMP notification obligation when an agency access request is denied, is in the Certification Data Sharing and Trust Center Policy and Procedures.

Approval and execution¶

Approval fires immediately, so the request has two meaningful states: raised and decided. The CAB decides on the justification recorded on the ticket. An approved request is executed in the identity provider by an implementer, and the completion is recorded on the same ticket that carried the approval, which is why the ticket is sufficient as the audit record for that account action.

A denied request is recorded as denied and closed. Denial leaves the account exactly as it was.

Evidence¶

The deployed User Access Request validation generator writes dated machine validation evidence on every access decision. Each run is a dated record carrying its method, its result, and its reference to the deciding ticket, and it lands on the validation structure described in the Continuous Monitoring and Reporting Policy and Procedures.

Two properties matter for the certification claim.

This pairing is the KSI-IAM-AAM claim: the account lifecycle is managed through a single automated request-and-approval path, and the automation writes the evidence that it ran.

Recertification and account compliance reviews¶

Recertification runs separately from the request process. It is a set of recurring compliance tasks, tracked with the rest of the recurring task program in the Continuous Monitoring and Reporting Policy and Procedures, not a stage inside a User Access Request.

The reviews decide; this process executes. A review that finds an account holds access it should not produces a change, and that change is raised as a User Access Request under the Access Recertification category. The connection is P-1, the every-account-action rule, rather than an integration between the review task and the request. That is worth stating plainly for two reasons: it explains why no automation links the two, and it means a review outcome is only real once its User Access Request exists.

Client responsibilities¶

This platform governs the access decision and its record. It does not configure the client's identity provider. Five KSI-IAM indicators describe practices that live in that provider's configuration, and they are the client's to implement and to evidence. They are stated here so the boundary is explicit and so a reader of this document knows what it does not claim.

How these are evidenced. The scheduled machine checks read the client's configuration and write dated validation evidence against these indicators on their schedule, the same path every scheduled check uses (Continuous Monitoring and Reporting Policy and Procedures). The client configures; the checks observe; the evidence lands in the same validation structure as everything else. This document makes no claim that the platform performs the configuration.

Where the client-owned and platform-owned halves meet. Suspicious activity is the clearest case. Detection and the response decision are the client's identity provider and the incident process; the account change that results is a User Access Request under Account Disable or Privileged Account Management, so the action is decided, recorded, and evidenced here even though the trigger was not.

Trust Center access¶

Agency and customer access to certification data rides this process. Portal accounts are created by self-registration or by request, and access to any certification-data surface is granted and removed through a User Access Request with the same approval and the same audit trail as staff access.

Two obligations sit on the sharing side rather than here, and the Certification Data Sharing and Trust Center Policy and Procedures owns both: the site-scoping and sensitive-field exclusion applied to a granted party's views, and the 5-business-day obligation to notify FedRAMP when an agency access request is denied, which is recorded on the User Access Request that carried the denial.

Records, retention, and metrics¶

Each User Access Request retains its category, target account, requester, justification, approver, decision, decision time, executed state, and the validation evidence the decision generated. User Access Request records are retained indefinitely and are never deleted, so the account history of any user is reconstructable from the request population alone.

Monthly metrics: requests raised and decided by category, privileged grants and removals, terminations and disablements, requests denied, recertification-category requests executed against the review outcomes that produced them, recurring review completion against due date, and validation evidence written per decision against decisions made (the two counts should match).

Authority, review, and revision¶

Issued under the authority of the System Owner and binding on all personnel with access to the system. Exceptions require written System Owner approval and are documented.

The ISSO reviews this document for effectiveness on the cadence in the Organization-defined values table, together with the recertification and account-review outcomes, and when frameworks, the system, or lessons learned warrant; the System Owner gives final approval.

Related documents¶

FedRAMP coverage¶

KSI-IAM-AAM, Automating Account Management: "The lifecycle and privileges of all accounts, roles, and groups are securely managed using automation." That is the indicator this document claims, and the User Access Request path plus the per-decision validation evidence is the claim.

Client-owned KSI-IAM indicators, evidenced through the scheduled checks and not performed by this platform: KSI-IAM-JIT (Authorizing Just-in-Time), KSI-IAM-ELP (Ensuring Least Privilege), KSI-IAM-APM (Adopting Passwordless Methods), KSI-IAM-SNU (Securing Non-User Authentication), KSI-IAM-SUS (Responding to Suspicious Activity).

Underlying NIST (KSI-IAM-AAM lineage, platform-claimed): AC-2 with AC-2(2), AC-2(3), AC-2(13), AC-6 with AC-6(7), IA-4(4), IA-12 with IA-12(2), IA-12(3), IA-12(5). Client-owned indicator lineage (IA-2, IA-5) rides the client responsibilities section.