Appearance
Regulatory & Content Change Impact
Where to find it: Policy Governance, then Change Impact (/governance/change-impact).
The Change Impact engine manages the ripple effects of regulatory reforms, statutory updates, and Content 2.0 version releases on internal governance structures. When external regulations or certified content change, the engine identifies affected downstream objects and initiates a governed, maker-checker assessment workflow.
Requires the policy_governance entitlement.
Core Objects & Workflow
Change impact operates through three distinct, tightly controlled constructs:
- Change Event (
CHG-YYYY-NNNN): The originating change notification (e.g. a new circular issued by a financial supervisory authority, or a new version release ofORV-PACK-CORE). - Impact Candidate: A downstream GRC object (policy, statement, control, risk, owner) identified through graph traversal as potentially affected.
- Impact Assessment (
IMP-YYYY-NNNN): A formal, governed evaluation of a candidate by a compliance assessor, establishing whether actual impact exists and defining required remediations.
Lifecycle States
1. Change Event States
A Change Event tracks five macro states:
| Status | Meaning |
|---|---|
detected | Change event registered; candidate generation pending |
in_review | Automated candidates generated; initial triage underway |
assessing | One or more active impact assessments are in progress |
closed | All assessments resolved and closure rationale independently verified |
dismissed | Event evaluated as completely inapplicable to this tenant |
2. Impact Candidate States
| Status | Meaning |
|---|---|
potential | Newly generated candidate; potential impact identified by graph engine |
assessed | Formal impact assessment created for this candidate |
dismissed | Candidate dismissed with mandatory documented rationale (e.g. out of scope) |
Candidate != Confirmed Impact
An impact candidate is an automated hypothesis generated by graph traversal. It does not represent a confirmed deficiency or required policy rewrite until an authorized human assessor completes a formal assessment.
3. Impact Assessment States & Dispositions
When assessing a candidate, the assessor selects an authoritative Disposition:
review_required: Preliminary state indicating detailed evaluation is needed.no_impact: Formally confirms the regulatory change does not affect this internal object.impact_confirmed: Confirms that the internal object is impacted and requires modification.
The assessment follows a two-tier governance and lifecycle track:
| Lifecycle Status | Meaning |
|---|---|
pending_review | Draft assessment awaiting formal submission |
action_required | Impact confirmed; remediation tasks or policy revisions must be created |
remediation_in_progress | Linked remediation actions (policy draft, control update, risk review) underway |
no_impact | Concluded without action; verified by checker |
resolved | All required remediations completed, verified, and closed |
Maker-Checker Segregation of Duties
To prevent arbitrary policy alterations or unverified claims of "no impact", high-impact change assessments enforce Maker-Checker Segregation of Duties:
- Assessment (Maker): An analyst holding
change_impact.assessreviews the change event, evaluates the candidate, assigns a disposition, and drafts remediation actions. - Submission: The analyst submits the assessment for independent governance approval.
- Approval (Checker): An authorized manager holding
change_impact.approvereviews the analysis, evidence, and remediation plans. - Hard SoD Rule: The platform strictly enforces that the user who authored the assessment (
assessor_id) cannot approve it (reviewer_id != assessor_id).
Polymorphic Target Objects
The engine can trace and evaluate changes against 15 distinct operational entity types:
| Target Type | Target Identification | Impact Consequence |
|---|---|---|
policy | POL-... | Triggers a draft version creation for policy revision |
policy_statement | PST-... | Identifies specific clause text needing amendment |
control | CTL-... | Flags control for design or operational test review |
risk | RSK-... | Prompts inherent and residual risk re-assessment |
scope / asset | SCP-... / AST-... | Re-evaluates applicability of technology or populations |
owner | User / Role / OrgUnit | Alerts accountable executives of changing governance duties |
evidence_expectation | EXP-... | Updates required observation artefacts and telemetry |
exception | EXC-... | Prompts immediate review of active temporary deviations |
action_plan | ACT-... | Tracks operational engineering milestones |
requirement | REQ-... | Updates mapped obligation baselines |
Semantic Doctrine
Semantic Doctrine: Change Detection != Compliance Change
- Change detection does not alter compliance status: The arrival of a new regulatory circular or content update generates review candidates; it does not automatically invalidate existing policies or degrade compliance scores.
- Candidate is not impact: Traversal candidates highlight potential exposure; impact is confirmed only through human maker-checker evaluation.
- Published does not mean compliant: Having published policies that incorporate change updates proves written adaptation; it does not prove operational adherence.
Permissions Reference
| Action | Permission Key | Required Role(s) |
|---|---|---|
| View change events, candidates, and assessments | change_impact.read | All compliance and risk roles, Auditor |
| Triage events, generate candidates, create assessments (Maker) | change_impact.assess | Tenant Admin, Compliance Manager, Compliance Officer |
| Approve impact dispositions and close assessments (Checker) | change_impact.approve | Tenant Admin, Compliance Manager (never the assessor) |