This post explains how to create a defensible, auditable authorization workflow that satisfies FAR 52.204-21 and CMMC 2.0 Level 1 control AC.L1-B.1.I — focusing on written policies, repeatable procedures, and automation patterns a small business can implement immediately to control who gets access to systems and data.
\n\nUnder the Compliance Framework Practice, AC.L1-B.1.I requires a documented policy and procedures that govern authorization and access, together with practical automation to enforce and evidence that policy. Key objectives include (1) defining who can approve access, (2) enforcing least privilege, (3) demonstrating timely provisioning and deprovisioning, and (4) maintaining auditable logs and periodic attestation. Your artifacts should show both the “what” (policy) and the “how” (procedures + automation) for routine access lifecycle events.
\n\nBegin by drafting an Authorization Policy that maps to the Compliance Framework Practice: scope (systems and data covered), roles (requester, manager, approver, IAM admin), approval rules (which roles may grant which access levels), and evidence retention windows. Complement this with a Procedure SOP that describes the step-by-step request, approval, provisioning, and deprovisioning workflows and the automation tools used (IdP, SCIM connector, ticketing system). Include decision trees for exceptions (emergency access, third-party contractors) and designate who performs quarterly attestation.
\n\nTechnical controls translate the policy into action. Use an Identity Provider (IdP) that supports SAML/OIDC for SSO and SCIM 2.0 for automated provisioning—examples: Okta, Azure AD, Google Workspace. Implement RBAC (role-based access control) with clearly defined role templates (e.g., Sales-Read, Dev-Deploy). For elevated access use time-limited Just-In-Time (JIT) provisioning or a Privileged Access Management (PAM) solution. Require MFA at the IdP layer and enforce session timeout policies (recommend 15–60 minutes for sensitive apps). Use automatic deprovisioning via SCIM when HR signals termination (integration with HR system or a simple webhook from your ticketing system) to ensure access is removed within your target SLA (commonly within 24 hours).
\n\nExample: a 20-person consultancy uses Google Workspace for email, AWS for hosting, and a cloud CRM. Implementation steps: (1) Create an Authorization Policy stating who may approve CRM access (team lead + security designee). (2) Use Okta as IdP and configure SCIM to provision users to the CRM and AWS IAM Identity Center; map job titles to role templates. (3) Use a simple ServiceNow or JIRA request form that routes to the team lead; Okta Workflows then applies the role on approval and sends a ticket closure with provisioning evidence. (4) Configure a daily deprovisioning sync and ensure HR offboarding triggers deletion in Okta so accounts are disabled within 24 hours of termination. Capture screenshots of approvals and CSV exports of provisioning logs for evidence during audits.
\n\nTo satisfy auditors, collect machine-readable evidence: IdP audit logs (user creation, role assignment, MFA events), SCIM provisioning logs, ticketing system approval records, and periodic attestation reports. Forward IdP logs and application audit events to a central SIEM or even a managed log storage (syslog + filebeat to a cloud log bucket) and retain them per your policy (typical retention: 1–3 years for contractual evidence). Create a simple quarterly attestation spreadsheet or automated report showing active roles, last access timestamps, and outstanding privileged accounts for manual review.
\n\nFailing to implement these controls introduces multiple risks: unauthorized access to covered contractor information and CUI, inability to demonstrate compliance during FAR or CMMC assessments, longer mean time to remediate after a departure or compromise, and potential contract loss or financial penalties. Operationally you also expose yourself to insider threats and accidental data exposure when least privilege is not enforced or deprovisioning is slow or manual.
\n\nPractical tips: (1) Start small — automate one critical app first (e.g., email or CRM), then expand. (2) Keep policies concise and map each policy statement to the procedural step and the evidence artifact (e.g., “Manager approval” → ticket ID and approver signature). (3) Use SCIM for provisioning and a webhook from HR to trigger deprovisioning; if SCIM is unavailable, create a daily reconciliation script that compares HR roster to IdP and flags mismatches. (4) Document exceptions and require time-limited access with automated expiry; log emergency access and require post hoc approvals. (5) Run tabletop exercises quarterly to validate that the workflow, notifications, and automations operate as expected.
\n\nIn summary, satisfying FAR 52.204-21 and CMMC 2.0 Level 1 control AC.L1-B.1.I is achievable for small businesses by writing clear authorization policies, codifying procedures, and implementing straightforward automation (IdP + SCIM + ticketing + logging). Prioritize least privilege, timely deprovisioning, and auditable evidence collection — do that and you'll both reduce operational risk and be prepared for compliance assessments.
", "plain_text": "This post explains how to create a defensible, auditable authorization workflow that satisfies FAR 52.204-21 and CMMC 2.0 Level 1 control AC.L1-B.1.I — focusing on written policies, repeatable procedures, and automation patterns a small business can implement immediately to control who gets access to systems and data.\n\nRequirement and key objectives (Compliance Framework / Practice)\nUnder the Compliance Framework Practice, AC.L1-B.1.I requires a documented policy and procedures that govern authorization and access, together with practical automation to enforce and evidence that policy. Key objectives include (1) defining who can approve access, (2) enforcing least privilege, (3) demonstrating timely provisioning and deprovisioning, and (4) maintaining auditable logs and periodic attestation. Your artifacts should show both the “what” (policy) and the “how” (procedures + automation) for routine access lifecycle events.\n\nImplementation notes for Compliance Framework\nBegin by drafting an Authorization Policy that maps to the Compliance Framework Practice: scope (systems and data covered), roles (requester, manager, approver, IAM admin), approval rules (which roles may grant which access levels), and evidence retention windows. Complement this with a Procedure SOP that describes the step-by-step request, approval, provisioning, and deprovisioning workflows and the automation tools used (IdP, SCIM connector, ticketing system). Include decision trees for exceptions (emergency access, third-party contractors) and designate who performs quarterly attestation.\n\nTechnical implementation: identity, provisioning, and enforcement\nTechnical controls translate the policy into action. Use an Identity Provider (IdP) that supports SAML/OIDC for SSO and SCIM 2.0 for automated provisioning—examples: Okta, Azure AD, Google Workspace. Implement RBAC (role-based access control) with clearly defined role templates (e.g., Sales-Read, Dev-Deploy). For elevated access use time-limited Just-In-Time (JIT) provisioning or a Privileged Access Management (PAM) solution. Require MFA at the IdP layer and enforce session timeout policies (recommend 15–60 minutes for sensitive apps). Use automatic deprovisioning via SCIM when HR signals termination (integration with HR system or a simple webhook from your ticketing system) to ensure access is removed within your target SLA (commonly within 24 hours).\n\nSmall-business example: 20-employee services firm\nExample: a 20-person consultancy uses Google Workspace for email, AWS for hosting, and a cloud CRM. Implementation steps: (1) Create an Authorization Policy stating who may approve CRM access (team lead + security designee). (2) Use Okta as IdP and configure SCIM to provision users to the CRM and AWS IAM Identity Center; map job titles to role templates. (3) Use a simple ServiceNow or JIRA request form that routes to the team lead; Okta Workflows then applies the role on approval and sends a ticket closure with provisioning evidence. (4) Configure a daily deprovisioning sync and ensure HR offboarding triggers deletion in Okta so accounts are disabled within 24 hours of termination. Capture screenshots of approvals and CSV exports of provisioning logs for evidence during audits.\n\nLogging, monitoring, and evidence collection\nTo satisfy auditors, collect machine-readable evidence: IdP audit logs (user creation, role assignment, MFA events), SCIM provisioning logs, ticketing system approval records, and periodic attestation reports. Forward IdP logs and application audit events to a central SIEM or even a managed log storage (syslog + filebeat to a cloud log bucket) and retain them per your policy (typical retention: 1–3 years for contractual evidence). Create a simple quarterly attestation spreadsheet or automated report showing active roles, last access timestamps, and outstanding privileged accounts for manual review.\n\nRisks of not implementing a proper authorization workflow\nFailing to implement these controls introduces multiple risks: unauthorized access to covered contractor information and CUI, inability to demonstrate compliance during FAR or CMMC assessments, longer mean time to remediate after a departure or compromise, and potential contract loss or financial penalties. Operationally you also expose yourself to insider threats and accidental data exposure when least privilege is not enforced or deprovisioning is slow or manual.\n\nCompliance tips and best practices\nPractical tips: (1) Start small — automate one critical app first (e.g., email or CRM), then expand. (2) Keep policies concise and map each policy statement to the procedural step and the evidence artifact (e.g., “Manager approval” → ticket ID and approver signature). (3) Use SCIM for provisioning and a webhook from HR to trigger deprovisioning; if SCIM is unavailable, create a daily reconciliation script that compares HR roster to IdP and flags mismatches. (4) Document exceptions and require time-limited access with automated expiry; log emergency access and require post hoc approvals. (5) Run tabletop exercises quarterly to validate that the workflow, notifications, and automations operate as expected.\n\nIn summary, satisfying FAR 52.204-21 and CMMC 2.0 Level 1 control AC.L1-B.1.I is achievable for small businesses by writing clear authorization policies, codifying procedures, and implementing straightforward automation (IdP + SCIM + ticketing + logging). Prioritize least privilege, timely deprovisioning, and auditable evidence collection — do that and you'll both reduce operational risk and be prepared for compliance assessments." }, "metadata": { "description": "Step-by-step guidance to design an authorization workflow that meets FAR 52.204-21 and CMMC 2.0 Level 1 AC.L1-B.1.I, including policies, automation patterns, and small-business examples.", "permalink": "/how-to-build-an-authorization-workflow-that-satisfies-far-52204-21-cmmc-20-level-1-control-acl1-b1i-policies-procedures-and-automation.json", "categories": [], "tags": [] } }