Regulatory change to assurance¶
Trigger¶
A new or changed law, regulation, supervisory expectation or contractual compliance obligation may affect IS/IT services, controls or architecture.
Intended outcome¶
Applicability and obligations are translated into traceable requirements/controls, architecture and remediation changes are implemented, evidence is independently assured, and closure is authorised.
Workflow steps and gates¶
| Step | Accountable role | Activity | Handover | Gate |
|---|---|---|---|---|
| 1 | Compliance Officer (Technology) | records authoritative regulatory change source, effective dates and scope hypotheses | regulatory change record | Source, jurisdiction, dates and version are attributable |
| 2 | Compliance Officer (Technology) | determines technology applicability with legal/business input where needed | applicability decision | In/out-of-scope rationale and authority are explicit |
| 3 | GRC Analyst | decomposes applicable obligations into traceable obligation records | obligations register | Each obligation retains source citation/context and applicability owner |
| 4 | Business Analyst | translates obligations into atomic/testable business/technology requirements | requirements baseline | Requirements preserve obligation intent and are testable |
| 5 | Control Owner | maps requirements to existing/new controls and identifies gaps | control mapping and gap register | Every requirement maps to effective control evidence or an owned gap |
| 6 | Enterprise Architect | assesses architecture/process/data/service impact and target-state changes | architecture impact assessment | Cross-domain impacts and affected governed models are explicit |
| 7 | Portfolio Manager | prioritises/funds time-bound remediation according to effective dates and risk | remediation roadmap | Mandatory deadlines and dependencies are funded/owned or escalated |
| 8 | Control Owner | coordinates implementation evidence and control operating proof | evidence pack | Evidence is attributable to implemented control version and period |
| 9 | Internal IT Auditor | independently tests design/operating evidence against obligation/control criteria | assurance report | Assurance is independent and reports exceptions/limitations |
| 10 | Compliance Officer (Technology) | authorises or routes closure based on assurance and residual exceptions | closure decision | Closure states remaining exceptions, authority and future review triggers |
Running this workflow: operator and implementer boundary¶
In Claude Code or Codex CLI, use the prompt in the next section (or adapt it to your programme): it is a provider conversation request, not a shell program named after this workflow. You supply the source materials, actual owners, gate acceptance and any authorisation for changing real systems. The provider agent interprets the registered workflow stages and role contracts, calls supported tools if allowed, and returns explicit evidence and blockers. Stage completion in the diagram or metadata is not proof of a successful external tool call, an approved exception or a released system.
For consequential decisions explicitly start /layered (Claude) or $workflow-layered (Codex); this version does not force every direct/natural-language workflow invocation into Fabric. Human L0 authority remains separate, with Codex requiring the actual human to run any protected authority command in a trusted terminal. See the interaction model, layered engagement and human authority.
How to use this workflow¶
A practical prompt pattern is:
Apply the
regulatory-change-to-assuranceworkflow to this situation. For each step, identify the current state, accountable role, required evidence, hand-over artefact, gate status and unresolved blocker. Do not skip a gate merely because the implementation is technically complete.
Operational interpretation¶
The workflow is most useful when the team keeps each hand-over explicit. The system can help generate or review the artefacts, but the accountable role and approval decision remain organisational responsibilities.