Controls Management Workflow for IT Compliance

End-to-End Example: RBAC Enforcement Control

Follow how Sarah, a Compliance Administrator, creates and manages a Role-Based Access Control (RBAC) enforcement check that satisfies policy for Least Privilege requirements, enforces the organization's Data Access Policy, and mitigates the Over-Privileged Access risk.

Phase 1: Define the Control and Procedure

Sarah starts by creating a Compliance Procedure called Production Access Management. This procedure groups all controls related to managing access rights in production systems.

Under this procedure, she creates a Compliance Control called RBAC Enforcement Check. The control's objective is to verify that all production system users have role-based access rights aligned with their job functions, and that no user has over-privileged access to customer data.

Sarah creates a Compliance Control Version RBAC Enforcement Check(v1.0) and documents the control's scope, frequency (quarterly), and expected evidence (screenshots of IAM role assignments, CSV exports of user-to-role mappings).

Phase 2: Map the Control to Regulations, Policies, and Business Processes

Sarah maps the control version to the records it enforces and protects. She uses junction records to create traceable links:

• Regulation mapping: She links the control version to the policy for Logical and Physical Access regulation clause using a Regulation Clause Version Compliance Control Version record. This mapping proves that the control satisfies the external regulatory requirement.
• Policy mapping: She links the control version to the Data Access (RBAC with Least Privilege) policy clause using a Compliance Policy Clause Version Compliance Control Version record. This mapping shows that the control enforces the internal policy.
• Business process mapping: She links the control version to the Customer Data Processing business operations process using a Business Operations Process Compliance Control Version record. This mapping shows that the control protects the organization's core customer data workflow.
• Asset mapping: She links the control version to the production AWS accounts tracked as assets in the CMDB. This mapping allows asset owners to see which compliance obligations apply to their systems.

Phase 3: Link the Control to the Risks It Mitigates

Sarah has already registered a Compliance Risk called Over-Privileged Access to Customer Data. This risk describes the threat that IT personnel could gain unauthorized access to customer data due to excessive permissions. Now she links the RBAC Enforcement Check control to this risk to show how the control reduces the risk's severity.

She creates a Compliance Control Version Risk record that links the control version to the risk. She assigns a control effectiveness rating of 80% effective, indicating that when the control is operating correctly, it reduces the risk's impact by 80%.

If the inherent risk score is 12 (Medium likelihood × High impact) and the control effectiveness is 80%, the residual risk becomes:

Residual Risk = 12 × (1 - 0.80) = 2.4 (Low)

This calculation shows stakeholders that the RBAC control is providing substantial risk reduction. If the control later fails a test, the effectiveness rating drops to 0%, and the residual risk reverts to the inherent risk level of 12, triggering alerts and remediation workflows.

Phase 4: Define and Execute Compliance Tests

Sarah creates a Compliance Test called Quarterly RBAC Audit.

She links the test to the control version using a Compliance Control Version Test record. She schedules the test to run quarterly, with the first execution on March 31, 2024.

When the test runs, the system creates a Compliance Control Version Test Execution record with the result Passed. The execution record captures these details:

• Execution date and time
• Pass/fail result
• Evidence collected (screenshots of IAM roles, CSV export of user-to-role mappings)
• Tester name (if manual) or automated test script ID (if automated)
• Observations and notes

Because the test passed, the control effectiveness rating remains at 80%, and the residual risk score stays at 2.4 (Low). The compliance team is confident that the control is operating as intended.

Phase 5: Controls Feed into Evidence Collection

During a compliance audit review, David, the Audit Program Manager, creates an Evidence Request called Production RBAC Configuration Evidence. He links the evidence request to the RBAC Enforcement Check control version to show which safeguard is being audited.

James, the Evidence Fulfiller, collects the required proof and submits an Evidence Artifact that includes:

• Screenshots of IAM role configurations
• CSV export of user-to-role mappings
• Screenshots of MFA enforcement settings

When the compliance reviewer accepts the artifact, it locks immediately, preserving chain of custody for external auditors. The artifact is linked back to the control version, creating a traceable connection from the regulation requirement through the control to the verified evidence that proves the control works.

Phase 6: Control Failure Triggers Remediation

In Q2, the Quarterly RBAC Audit test runs again. This time the result is Failed. The test detected that three users in the IT operations team have administrative access rights that exceed their job function requirements.

The moment the test fails, several things happen automatically.

• Because the control failed its test, the effectiveness rating is reset to 0%.
• The Business Rules Engine recalculates the residual risk. With 0% control effectiveness, the residual risk reverts to the inherent risk level: Residual Risk = 12 × (1 - 0.00) = 12 (High). The risk level jumps from Low to High.
• A background monitoring agent detects the control failure and creates a Compliance Finding.
• Maria, the risk owner for Over-Privileged Access, receives an alert that the residual risk score has increased from 2.4 to 12.

Sarah converts the finding into a Compliance Issue called Over-Privileged Access Rights Detected in IT Ops Team. She links the issue to the control version, the risk, the regulation clause, and the policy clause. She applies an out-of-the-box Remediation Action Plan Template that includes tasks to review user access rights, revoke excessive permissions, and re-run the control test.

Maria and her team complete the remediation work. They revoke the excessive permissions and re-run the RBAC test. The result is: Passed. The control effectiveness rating is restored to 80%, and the residual risk score drops back to 2.4 (Low). The compliance issue is closed with evidence of remediation.

Phase 7: Continuous Monitoring and Control Evolution

Sarah configures a background monitoring agent to watch for changes in the production access control environment. The agent listens for:

• New users added to production systems
• Changes to IAM role assignments
• MFA enforcement policy updates
• Control test failures

When the agent detects a relevant change, it automatically triggers a new risk evaluation and notifies the risk owner. If the change represents a potential control weakness, the agent can create a proactive finding before the quarterly test runs.

Six months later, the compliance requirement is amended to require continuous monitoring instead of quarterly testing. Sarah clones the control version to create v2.0, updates the test frequency from quarterly to monthly, and retires v1.0. The new version inherits all the mappings to regulations, policies, risks, business processes, and assets from v1.0, preserving the audit trail while adapting to new requirements.