The Atlas covered the external laws. This guide covers the six internal records a firm uses to actually govern: its policies, controls, risks, mitigations, audit findings, and compliance mappings — with every real entry from the database explained.
The one idea to hold onto
The external frameworks tell you what's required. Everything below is how the organization responds — and each record links to the next, so you can trace any single safeguard from the rule that demands it all the way to the proof it works. Read the chain left to right:
The rules the organization writes for itself — each owned by a named executive.
A policy sets a requirement but doesn't enforce it; that's the controls' job. What to read on each: its owner (who's accountable) and its status — only an Active policy has real authority. Watch for the two that aren't active.
How personal data is collected, processed, and stored.
The master framework for protecting information assets.
Who can reach which systems — least privilege.
Detecting, responding to, and recovering from incidents.
Assessing and managing risk from outside vendors.
Keeping critical functions running through a disaster.
How long data is kept and how it's destroyed.
How employees may use company IT resources.
How changes to IT systems are approved and made.
Internal controls ensuring accurate financial reports (SOX).
Security requirements for cloud infrastructure.
Ethical development & deployment of AI — parent of all 12 AI controls.
Ten policies are Active; two aren't. The AI Governance Policy (P12) is only Under Review — yet it's the parent of every AI control. An un-ratified policy can't compel a control, so this single un-approved status is the root cause of the AI failures you'll see in every register below. Teaching point: governance maturity is visible in the status column before you read anything else.
The actual safeguards — grouped under the policy that authorizes each.
Each control has a type (Preventive / Detective / Corrective) and two health checks: does it exist (implementation) and does it work (effectiveness)? Expand each policy to see its controls. The contrast between the mature groups and the AI group is the whole story.
Read the pattern, not the rows: the seven traditional groups are dominated by Effective; the AI group has zero. Same company, same skill — simply never turned on AI. Also note P02 (Information Security), P07, P08, and P11 have no controls attached at all — a policy with no controls is unenforced intent, a coverage gap worth teaching.
What could go wrong — each scored Likelihood × Impact so it can be ranked.
Score bands: Low 1–5 Medium 6–11 High 12–19 Critical 20–25. AI-related rows are tinted. Notice how they crowd the top.
| # | Risk | Category | L×I | Score | Status | Owner |
|---|---|---|---|---|---|---|
| 16 | AI Act non-compliance — high-risk system · deploying without conformity assessment | AI Regulatory | 4×5 | 20 Critical | Open | CTO |
| 18 | AI training-data bias & quality · discriminatory outcomes | AI Governance | 4×4 | 16 High | Open | ML Eng |
| 20 | AI lifecycle compliance gap · no cradle-to-grave tracking | AI Regulatory | 4×4 | 16 High | Open | AI Ethics Board |
| 7 | Phishing campaign targeting executives | Cybersecurity | 4×4 | 16 High | Open | CISO |
| 11 | AI model bias in lending decisions · harms protected groups | Technology | 3×5 | 15 High | Open | CTO |
| 17 | AI lack of human oversight · consequential decisions unchecked | AI Governance | 3×5 | 15 High | Open | AI Ethics Board |
| 22 | AI fundamental-rights violation · no impact assessment | AI Governance | 3×5 | 15 High | Open | CPO |
| 1 | Data breach via third-party vendor | Third-Party | 3×5 | 15 High | Open | CISO |
| 2 | Ransomware attack | Cybersecurity | 3×5 | 15 High | Mitigated | CISO |
| 19 | AI transparency failure · can't explain decisions | AI Governance | 3×4 | 12 High | Open | ML Eng |
| 21 | Unregistered high-risk AI system · not in EU database | AI Regulatory | 3×4 | 12 High | Open | AI Ethics Board |
| 5 | Insider threat — data exfiltration | Cybersecurity | 3×4 | 12 High | Open | CISO |
| 12 | Supply-chain software vulnerability | Cybersecurity | 4×3 | 12 High | Open | VP Eng |
| 15 | Third-party API data leakage | Third-Party | 3×4 | 12 High | Open | VP Eng |
| 3 | GDPR non-compliance fine | Regulatory | 2×5 | 10 Med | Open | CPO |
| 9 | Privileged access abuse | Cybersecurity | 2×5 | 10 Med | Open | CISO |
| 10 | Business continuity plan failure | Operations | 2×5 | 10 Med | Open | COO |
| 8 | Regulatory change impact | Regulatory | 3×3 | 9 Med | Accepted | CPO |
| 14 | Incomplete audit trail | Compliance | 3×3 | 9 Med | Open | CISO |
| 4 | SOX material weakness | Financial | 2×4 | 8 Med | Open | CFO |
| 6 | Cloud service provider outage | Operations | 2×4 | 8 Med | Mitigated | CTO |
| 13 | Employee data privacy violation | Data Privacy | 2×3 | 6 Med | Mitigated | VP HR |
Eight AI risks; every one lands High or Critical, and the single Critical (#16, score 20) is an AI risk. The status column tells the treatment story: most are still Open, only a few Mitigated, and #8 is consciously Accepted — a deliberate governance decision, not neglect. Teaching point: the score decides priority; the status decides what you did about it.
The dated actions that reduce each risk — usually by building a control.
A mitigation links a risk to an action or control, picks a strategy (Avoid / Mitigate / Transfer / Accept), and carries a due date and status. The gap between “planned” and “completed” is where programs live or die. A few representative examples:
| Risk | Mitigation action | Via control | Status |
|---|---|---|---|
| R1 · Vendor breach | Vendor security assessment program | C13 | Completed |
| R2 · Ransomware | Immutable backups + DR plan | C16 | Completed |
| R5 · Insider threat | MFA + user-behavior analytics | C6 | In Progress |
| R16 · AI Act non-compliance | Conformity-assessment procedures for high-risk AI | C30 | Planned |
| R16 · AI Act non-compliance | Register AI systems in EU database | C26 | Planned |
| R17 · No human oversight | Deploy human-oversight mechanisms | C28 | In Progress |
| R18 · Training-data bias | AI data-governance framework + bias testing | C29 · C25 | Planned |
| R19 · Transparency failure | Explainability layer + Annex IV docs | C27 · C32 | In Progress |
| R22 · Fundamental rights | Conduct FRIA for all AI systems | C33 | Planned |
Of the 28 mitigations, the ones tied to traditional risks are frequently Completed; every mitigation tied to an AI risk is Planned or In Progress — never Completed. The intent is documented; the delivery is entirely outstanding. That plan-vs-done gap is the earliest, clearest signal of a program that's behind.
Gaps an independent examiner found in a specific control — each owned and dated.
Every finding points at a control and carries a severity, a remediation owner, and a due date. Grouped by severity — the Criticals are the worklist that comes first.
| Sev. | Finding | Control | Owner | Due |
|---|---|---|---|---|
| Critical | No conformity assessment completed for any AI system despite AI Act enforcement | C30 | AI Ethics Board | 2025-09-01 |
| Critical | No AI system registration process for EU AI Act compliance | C26 | AI Ethics Board | 2025-06-01 |
| Critical | Human override not available for AI credit-scoring | C28 | AI Ethics Board | 2025-05-01 |
| Critical | PAM not covering 3 legacy DB admin accounts | C9 | Identity Team | 2025-01-31 |
| Critical | Same person initiating & approving journal entries | C21 | Finance Ops | 2025-01-31 |
| High | No AI model risk-assessment framework (3 models live) | C24 | AI Ethics Board | 2025-06-01 |
| High | Chatbot gives no explanation for escalation | C27 | ML Engineering | 2025-06-01 |
| High | Fraud-AI training data not assessed for bias | C29 | Data Governance | 2025-07-01 |
| High | No fundamental-rights assessment for AI hiring tool | C33 | AI Ethics Board | 2025-07-01 |
| High | No lifecycle compliance tracking for 5 AI systems | C35 | AI Ethics Board | 2025-09-01 |
| High | Consent records missing for 12% of EU accounts | C4 | Privacy Team | 2025-02-01 |
| High | 15 dormant accounts with elevated privileges | C7 | Identity Team | 2025-02-15 |
| High | No continuous monitoring for 8 critical SaaS vendors | C14 | Vendor Risk | 2025-03-01 |
| High | DR failover test excluded payment systems | C17 | Infrastructure | 2025-03-15 |
| Medium | Post-mortems done for only 60% of P1 incidents | C12 | SOC Team | 2025-03-01 |
| Medium | Emergency changes bypassing CI/CD up 40% | C20 | DevOps | 2025-03-01 |
| Medium | 23 data assets not yet classified per policy | C1 | Data Governance | 2025-02-01 |
| Medium | Quarterly finance access review completed 2 weeks late | C8 | Identity Team | Closed |
Three of the five Critical findings are AI, and all point at controls that block deployment legality (conformity, registration, human override). Every AI finding is still Open. Teaching point: a finding's worth is the owned, dated commitment to fix it — the paperwork here is sound; the execution is late.
The crosswalk proving a control satisfies a specific legal requirement — with the evidence.
A mapping is a four-part link: a control, a framework requirement (e.g. “Art. 14”), a status, and — the field that decides everything — an evidence location. With 48 of them, don't read each; read the pattern. Compare a healthy mapping to a failing one:
| Control | Framework · requirement | Status | Evidence |
|---|---|---|---|
| C2 Encryption at Rest | GDPR · Art. 32 (Security) | Compliant | SharePoint/GRC/GDPR/Art32 |
| C21 Segregation of Duties | SOX · §302 | Compliant | SharePoint/GRC/SOX/Sec302 |
| C6 MFA | PCI DSS · Req 8.3 | Compliant | SharePoint/GRC/PCI/Req8 |
| C30 Conformity Assessment | AI Act · Art. 43 | Non-Compliant | (null) |
| C29 AI Data Governance | AI Act · Art. 10 | Non-Compliant | (null) |
| C24 AI Risk Classification | AICM · RM-01 | Non-Compliant | (null) |
| C25 AI Bias Testing | AIEU · FA-01 (Fairness) | Non-Compliant | (null) |
| C27 Transparency | AI Act · Art. 13 | Partially | SharePoint/GRC/AIAct/Art13 |
Across all 48: the 6 traditional frameworks (GDPR, SOX, HIPAA, ISO 27001, PCI, NIST) are almost entirely Compliant with real evidence paths. The 22 mappings to AI frameworks (AI Act, AICM, AIEU) are all Partial or Non-Compliant — and every Non-Compliant one has a null evidence field.
This is where the hardest truth in GRC becomes a single column: compliance is what you can prove. A control that works but has no evidence attached counts, to an auditor, as non-compliant. The traditional rows point at documents and read green; the AI rows point at nothing and read red. Same firm — the difference is entirely whether a proof exists.
The chain, in one breath
Follow a single thread through all six for this firm's AI problem:
The AI Governance Policy is only Under Review (Register 1), so its AI controls were never built (Register 2), which is exactly why the AI risks score High and Critical (Register 3), whose mitigations are all still Planned (Register 4); an auditor independently flagged the same gaps as Critical and Open (Register 5), and the compliance mappings confirm it with a wall of Non-Compliant, evidence: null (Register 6).
One un-ratified policy, traced through six records, into a wall of red. That traceability — from intent to proof — is the entire value of keeping these registers. Fix the root (ratify the policy, fund the board) and the whole chain can turn green.
The Operating Registers — a teaching guide to the six internal GRC records (policies, controls, risks, mitigations, audit findings, compliance mappings) in the project database. Companion to “The Regulatory Atlas,” “The Seven Building Blocks of GRC,” and the practitioner course “GRC for Generative AI.” All data is synthetic teaching material; examples are illustrative, not legal advice.