# NORTHBRIDGE BANK — PRE-FLIGHT COMPLIANCE REPORT
## AI Credit Re-Scoring Platform — Gate 3 Audit

---

| Field | Value |
|-------|-------|
| **Document ID** | TKA-NB-COMP-001 |
| **Engagement** | TKA-NB-20260702-001 |
| **Compliance Agent** | Themis — Compliance & QA Agent, Talastron Kinetic AI |
| **Date** | 2 July 2026 |
| **Stage** | Gate 3 — Pre-Build Compliance Pre-Flight |
| **Architecture reviewed** | TKA-NB-ADR-001 (v1) · TKA-NB-HLD-001 (v1) |
| **Classification** | RESTRICTED — FCA Consumer Credit // OFFICIAL-SENSITIVE |

---

## EXECUTIVE SUMMARY

The Vitruvius architecture for the NorthBridge AI Credit Re-Scoring Platform has been reviewed against six regulatory and standards frameworks. The architecture demonstrates materially strong security controls — Managed Identity, private endpoints, customer-managed encryption, Zero Trust, and a three-tier audit trail. These are not contested.

However, two items are formally **BLOCKED**. Both are UK GDPR statutory obligations that must be initiated and assigned to a named owner before Gate 3 can close. Neither can be retrospectively satisfied after build commences. Architecture may not proceed to Vulcan until these conditions are on record.

Fourteen items are **CONDITIONAL** — they do not block the build phase, but each carries a defined resolution deadline. Conditions not resolved by their stated deadline will escalate to BLOCKED at the relevant subsequent gate.

**Overall Gate 3 recommendation: CONDITIONAL — Two BLOCKED items must be resolved before Gate 3 is granted.**

---

## GATE 3 STATUS

```
╔══════════════════════════════════════════════════════════╗
║  GATE 3 — PRE-BUILD COMPLIANCE STATUS                    ║
║                                                          ║
║  BLOCKED items:       2   (must resolve before Gate 3)   ║
║  CONDITIONAL items:  14   (tracked; escalate if missed)  ║
║  GREEN items:        21                                  ║
║                                                          ║
║  GATE 3 STATUS:   BLOCKED — pending resolution           ║
╚══════════════════════════════════════════════════════════╝
```

---

## FRAMEWORK 1 — ISO 27001 INFORMATION SECURITY MANAGEMENT

| Control Area | Annex A Ref | RAG | Finding |
|-------------|-------------|-----|---------|
| Information security policies | A.5.1 | 🟡 CONDITIONAL | Orion delivery standards referenced but NorthBridge internal ISMS policy scope not confirmed. NorthBridge must confirm ISO 27001 certification scope covers this system. |
| Asset management — classification | A.8.2 | 🟢 GREEN | `data-classification: fca-consumer-credit` tag enforced via Bicep (ADR-008). Asset inventory reproducible from IaC. |
| Access control — least privilege | A.9.1 | 🟢 GREEN | Managed Identity throughout (ADR-005). RBAC roles explicitly scoped: `NB-Underwriter-Reviewer`, `NB-Compliance-ReadOnly`. No Owner/Contributor to application identities. |
| Access control — privileged access | A.9.4 | 🟢 GREEN | Azure Bastion in `snet-management`. No direct RDP/SSH exposure. |
| Cryptography — encryption at rest | A.10.1 | 🟡 CONDITIONAL | SQL and Blob use customer-managed keys (GREEN). Event Hubs uses Microsoft-managed encryption — CMK available but deferred. For an audit trail containing FCA consumer credit data, Microsoft-managed keys are an accepted risk that must be formally logged and signed off by NorthBridge's CISO. |
| Cryptography — in transit | A.10.1 | 🟢 GREEN | TLS 1.2 minimum enforced. Private endpoints eliminate public transit paths. |
| Operations security — logging | A.12.4 | 🟡 CONDITIONAL | Log Analytics deployed. Audit trail architecture is sound. Retention period not confirmed — placeholder is 7 years. Themis cannot close this control until the retention period is confirmed and the WORM lock duration is set. See BLOCKED item B2. |
| Communications security | A.13.1 | 🟢 GREEN | Private endpoints for all PaaS. Public network access disabled at resource level in Bicep. VNet with subnet segmentation. NSGs defined. |
| Secure development | A.14.2 | 🟢 GREEN | Bicep AVM IaC. GitHub Actions CI/CD with environment-gated deployments. Dev/prod separation. No hardcoded secrets (Key Vault enforced). |
| Supplier relationships — AISP | A.15.1 | 🟡 CONDITIONAL | APIM gateway controls are architecturally sound (ADR-004). However, no formal supplier security assessment or due diligence record for the AISP is referenced. A third-party FCA-regulated supplier carrying consumer financial data requires documented supplier assurance under A.15. Must be completed before the AISP integration is activated in production. |
| Incident management | A.16.1 | 🟡 CONDITIONAL | Azure Monitor alerting defined in HLD. No formal incident response playbook referenced. Azure Sentinel deferred to production hardening — this creates a detection gap for the MVP period. NorthBridge must confirm existing SOC capability covers this platform during MVP operation. |
| Business continuity | A.17.1 | 🟡 CONDITIONAL | Zone-redundant deployment within UK South. No cross-region DR by client constraint. RTO/RPO formally deferred. Acceptable for MVP — must be defined before production hardening gate. |
| Compliance | A.18.1 | 🟢 GREEN | CAF naming, FCA scope tags, compliance annotations in architecture. |

**ISO 27001 Summary: CONDITIONAL** — No hard blockers at architecture stage. Event Hubs CMK and incident response plan are the highest-priority items for production hardening.

---

## FRAMEWORK 2 — ISO 42001 AI MANAGEMENT SYSTEM

| Control Area | ISO 42001 Ref | RAG | Finding |
|-------------|--------------|-----|---------|
| AI policy | §5.2 | 🟡 CONDITIONAL | Responsible AI Dashboard mandated in ADR-002 demonstrates governance intent. No formal AI policy document referenced. NorthBridge must produce an AI policy scoping this system before production deployment. |
| AI risk assessment | §6.1 | 🟡 CONDITIONAL | Model risk partially addressed through SHAP + Responsible AI Dashboard. No formal AI risk register produced. Required before model training commences (aligns with Minerva C2). |
| AI system impact assessment | §6.2 | 🔴 **BLOCKED** | No AI impact assessment (AIIA) has been scoped or initiated for this system. ISO 42001 §6.2 requires an impact assessment for AI systems that make or influence decisions with significant consequences for individuals. Automated credit decisions are explicitly within scope. **This assessment must be formally scoped and assigned to a named owner before Gate 3 can close.** It need not be complete before build commences, but it must be in progress. |
| Model transparency | §8.4 | 🟢 GREEN | XGBoost/LightGBM selection justified in ADR-002. SHAP values captured per inference. Model cards version-controlled in Git. Gradient boosting family is interpretable and well-understood by regulators. |
| Model verification and validation | §8.5 | 🟡 CONDITIONAL | Model validation methodology not defined. Champion/challenger framework not referenced. Fairness testing process (protected characteristic analysis) is available via Responsible AI Dashboard but no testing protocol is defined. Must be documented before model training commences. |
| AI system documentation | §8.6 | 🟢 GREEN | Model cards (ADR-002). Prompt template version control (ADR-003). Decision audit trail (ADR-006). Architecture artefacts (ADR + HLD). Documentation chain is substantive. |
| Monitoring for model drift | §9.1 | 🟢 GREEN | AML data drift monitor configured. PSI >0.15 alert defined in HLD. This is a genuine operational control, not a placeholder. |
| Model retraining | §10.1 | 🟡 CONDITIONAL | Retraining pipeline deferred to production hardening. Acceptable for MVP. Must be in place before the model's initial training data becomes stale — typically 6 months for credit scoring models. |
| Bias and fairness | §8.4 | 🟡 CONDITIONAL | Responsible AI Dashboard provides fairness metrics. Protected characteristics (age, gender, ethnicity, disability) must be explicitly included in fairness evaluation before model is deployed. This is both an ISO 42001 and Equality Act 2010 obligation. |

**ISO 42001 Summary: BLOCKED** — AI impact assessment must be initiated. This is a pre-Gate 3 requirement.

---

## FRAMEWORK 3 — FCA SYSC 6.3 OPERATIONAL RESILIENCE

| Control Area | SYSC Ref | RAG | Finding |
|-------------|----------|-----|---------|
| Important Business Service identification | SYSC 6.3.1 | 🟡 CONDITIONAL | Mortgage credit decisioning is clearly an Important Business Service under FCA PS21/3 (effective March 2025). Architecture does not reference NorthBridge's existing IBS mapping. NorthBridge must confirm this system has been added to their IBS register before production deployment. |
| Impact tolerance definition | SYSC 6.3.4 | 🟡 CONDITIONAL | Impact tolerances (maximum tolerable disruption) not defined in architecture. Deferred to production hardening. Must be defined before the system is registered as an IBS. |
| Mapping of dependencies | SYSC 6.3.5 | 🟢 GREEN | HLD component inventory and data flows provide substantive dependency mapping. AISP, Dataverse, Azure SQL, AML, OpenAI all identified as dependencies with integration paths documented. |
| Single-region constraint | SYSC 6.3 | 🟡 CONDITIONAL | UK South only by client mandate. If the system is an FCA IBS, the organisation must be able to demonstrate that a UK South Azure regional disruption will not cause NorthBridge to exceed its impact tolerance. No evidence this assessment has been made. **This must be reviewed by NorthBridge's operational resilience function before production deployment.** |
| Operational resilience testing | SYSC 6.3.9 | 🟡 CONDITIONAL | No testing plan referenced. Testing obligation applies from the system's first registration as an IBS. Deferred testing is acceptable for MVP given 90-day window, but the testing schedule must be defined. |
| Scenario testing | SYSC 6.3 | 🟡 CONDITIONAL | No severe-but-plausible scenario testing plan. Must be scheduled for the period immediately following MVP delivery. |

**FCA SYSC 6.3 Summary: CONDITIONAL** — Architecture provides the technical foundation. Operational resilience programme obligations are a NorthBridge-side governance requirement that must be initiated in parallel with the build.

---

## FRAMEWORK 4 — FCA CONSUMER DUTY — AI DECISION EXPLAINABILITY

| Control Area | Consumer Duty Ref | RAG | Finding |
|-------------|------------------|-----|---------|
| Products and services outcome | Chapter 4 | 🟢 GREEN | Re-scoring layer designed to improve access to appropriate mortgage products. Directly aligned with the products and services outcome. |
| Price and value outcome | Chapter 5 | 🟢 GREEN | Out of scope for this architecture — not contested. |
| Consumer understanding outcome | Chapter 6 | 🟡 CONDITIONAL | ADR-003 provides the capability to generate plain-English rationale. The rationale output format has not been validated against Consumer Duty communications standards (clear, fair, not misleading). Themis requires sight of a sample rationale output and consumer testing evidence before this control can be closed. |
| Adverse decision communication | Consumer Duty / CONC | 🟡 CONDITIONAL | Architecture delivers the rationale text. The web portal's presentation of that rationale to the applicant is out of architecture scope. NorthBridge must confirm the portal presents rationale in a manner that: (a) tells the applicant what factors led to the decision, (b) tells the applicant what they can do to address those factors, (c) informs the applicant of their right to request human review. |
| Human review pathway | Art 22 / Consumer Duty | 🟢 GREEN | Underwriter review pathway is architecturally implemented. Conditional decisions are queued for human review. Override records are audit-trailed. This satisfies the right to human intervention. |
| Consumer vulnerability | FCA FG21/1 | 🟡 CONDITIONAL | No vulnerability screening referenced in the architecture. NorthBridge must confirm whether the existing web portal's vulnerability identification processes extend to this re-scoring layer. |
| OpenAI rationale generation — Consumer Duty adequacy | ADR-003 | 🟡 CONDITIONAL | Constrained prompting design is the correct approach. However, the prompt template has not been reviewed by a Consumer Duty compliance officer. Before the OpenAI rationale endpoint is activated in production, the template must be signed off by NorthBridge's compliance function. Any subsequent change to the template is a regulated communications change. |

**FCA Consumer Duty Summary: CONDITIONAL** — Architecture intent is sound. Rationale format validation and portal presentation design must be completed before production activation.

---

## FRAMEWORK 5 — NCSC CYBER ASSESSMENT FRAMEWORK (CAF)

| Objective | CAF Principle | RAG | Finding |
|-----------|--------------|-----|---------|
| A — Managing security risk | A1: Governance | 🟡 CONDITIONAL | Architecture-level governance is strong (Orion delivery standards, Bicep AVM, CI/CD gates). NorthBridge organisational cyber security governance is assumed — not evidenced in the architecture artefacts. |
| A — Managing security risk | A2: Risk management | 🟢 GREEN | Private endpoints for all PaaS. Zero Trust implemented. APIM WAF for external ingress. No public attack surface. ADR-007 directly addresses A2. |
| A — Managing security risk | A3: Asset management | 🟢 GREEN | IaC ensures full, reproducible asset inventory. CAF naming convention applied. |
| A — Managing security risk | A4: Supply chain | 🟡 CONDITIONAL | AISP is the primary supply chain dependency. APIM gateway controls the technical interface (GREEN). No supplier security assessment documented. Formal supply chain risk management under A4 requires documented assurance of the AISP's security posture. |
| B — Protecting against cyber attack | B1: Service protection | 🟢 GREEN | No public endpoints. APIM WAF (OWASP CRS 3.2). Private DNS. Private endpoints. |
| B — Protecting against cyber attack | B2: Identity and access | 🟢 GREEN | Managed Identity. Entra ID. Conditional Access. Least privilege RBAC. No credential-based auth. |
| B — Protecting against cyber attack | B3: Data security | 🟢 GREEN | CMK for SQL and Blob. TLS 1.2 minimum. Private endpoints. |
| B — Protecting against cyber attack | B4: System security | 🟢 GREEN | Bicep AVM. GitHub Actions with approval gates. Dev/prod separation. No hardcoded secrets. |
| B — Protecting against cyber attack | B5: Resilient networks | 🟢 GREEN | VNet with subnet segmentation. NSGs. Azure Bastion for management access. |
| C — Detecting cyber security events | C1: Security monitoring | 🟢 GREEN | Log Analytics. Azure Monitor alerts on authentication anomalies, Key Vault access, decision error rates. |
| C — Detecting cyber security events | C2: Proactive discovery | 🟡 CONDITIONAL | Azure Sentinel deferred to production hardening. During MVP operation, proactive threat detection capability is reduced. NorthBridge's existing SOC must confirm coverage for this platform. |
| D — Minimising impact | D1: Response and recovery | 🟡 CONDITIONAL | No incident response playbook. DR deferred. Acceptable for MVP — must be completed before production hardening gate. |

**NCSC CAF Summary: CONDITIONAL** — Security controls are architecturally strong. Organisational governance evidence, supply chain assurance, and active threat detection are gaps that must be addressed before production hardening.

---

## FRAMEWORK 6 — UK GDPR DATA PROTECTION

| Control Area | GDPR Article | RAG | Finding |
|-------------|-------------|-----|---------|
| Lawful basis — credit data processing | Art 6(1)(b) | 🟢 GREEN | Processing of applicant data for credit decisioning is lawful under contractual necessity (Art 6(1)(b)). Assumed confirmed — NorthBridge's existing FCA authorisation covers this. |
| Data minimisation | Art 5(1)(c) | 🟡 CONDITIONAL | Open banking enrichment scope is defined as "open banking feeds, affordability signals." The specific data fields ingested from the AISP have not been enumerated. A data minimisation review must confirm that only fields directly relevant to re-scoring are ingested — no surplus collection. Must be completed before AISP integration is activated. |
| Purpose limitation | Art 5(1)(b) | 🟢 GREEN | Architecture is scoped exclusively to credit re-scoring. Audit data is retained for regulatory compliance purposes — a compatible purpose. |
| Storage limitation | Art 5(1)(e) | 🟡 CONDITIONAL | Retention periods not confirmed. Placeholder of 7 years is consistent with FCA consumer credit record requirements but must be formally confirmed by NorthBridge's Data Protection Officer before the WORM lock is applied. |
| Special category data | Art 9 | 🟡 CONDITIONAL | Affordability signals from open banking data may infer special category characteristics (health-related spending, disability indicators, family composition). A formal assessment of whether special category data is likely to be present in the feature set is required. If present, explicit consent or substantial public interest basis must be established. |
| Privacy information — applicant notification | Art 13/14 | 🟡 CONDITIONAL | Applicants must be informed that their data is processed by an AI-assisted system. Not referenced in the architecture — assumed to be handled by the existing web portal privacy notice. NorthBridge must confirm the portal's privacy notice has been updated to reflect AI-assisted credit decisioning. |
| Automated decision-making — lawful basis | Art 22(2) | 🔴 **BLOCKED** | Art 22 applies to decisions based solely or substantially on automated processing that produce legal or similarly significant effects. Credit decisions are the textbook case. The lawful basis for automated processing under Art 22(2) must be formally documented before this architecture is locked. Art 22(2)(a) — necessary for entering into a contract — is the expected basis, but it must be on record, documented in the ROPA, and communicated to data subjects. **This documentation must be produced and assigned to a named owner (DPO) before Gate 3 closes.** |
| Data subject rights — right to erasure vs. WORM storage | Art 17 / ADR-006 | 🔴 **BLOCKED** | ADR-006 implements immutable WORM storage for audit records. Art 17 grants data subjects the right to erasure. These are in direct conflict. The architecture cannot be finalised until the legal basis for refusing erasure requests in respect of audit records is formally confirmed. The expected exemption is Art 17(3)(b) — compliance with a legal obligation (FCA audit retention requirements). However, this exemption must be formally documented and confirmed by NorthBridge's DPO before the WORM architecture is locked. **This is an architectural decision, not a process gap — WORM is irreversible once applied.** |
| Data Processing Agreement — AISP | Art 28 | 🟡 CONDITIONAL | The AISP is a data processor. A Data Processing Agreement (DPA) under Art 28 is required before the integration is activated. Not referenced in the architecture. Must be executed before live data flows commence. |
| Data Protection Impact Assessment | Art 35 | 🔴 **BLOCKED** | See dedicated BLOCKED item log below. |

**UK GDPR Summary: BLOCKED** — Three items require formal initiation before Gate 3 closes. Two are directly architectural (Art 22 lawful basis documentation, Art 17 WORM conflict resolution). One is process (DPIA initiation).

---

## BLOCKED ITEMS — GATE 3 RESOLUTION REQUIRED

### BLOCK-01 — UK GDPR Art 35: Data Protection Impact Assessment Not Initiated

| Field | Detail |
|-------|--------|
| **Framework** | UK GDPR Article 35 |
| **Finding** | Processing of personal data using automated decision-making in a credit context constitutes high-risk processing under Art 35(3)(a). A DPIA is a statutory requirement before processing commences. No DPIA has been scoped, initiated, or assigned. |
| **Why this blocks Gate 3** | A DPIA cannot be conducted retrospectively on a system already built. It must be in progress before design is finalised. The DPIA findings may require architectural changes — if those changes are discovered after Vulcan builds, the cost is substantially higher. |
| **Resolution** | NorthBridge's Data Protection Officer must formally initiate the DPIA, assign a lead, and confirm scope in writing. The DPIA need not be complete before Gate 3 closes — it must be in progress with a defined completion date prior to production go-live. |
| **Escalation if unresolved** | Gate 3 remains BLOCKED. |

---

### BLOCK-02 — UK GDPR Art 17 vs. ADR-006: Right to Erasure Conflict with WORM Architecture

| Field | Detail |
|-------|--------|
| **Framework** | UK GDPR Article 17 / ADR-006 |
| **Finding** | ADR-006 specifies immutable WORM storage for FCA audit records. WORM storage, once applied, is irreversible — data cannot be deleted. UK GDPR Article 17 grants data subjects the right to erasure. These are in direct legal conflict. The exemption at Art 17(3)(b) — compliance with a legal obligation — is the expected resolution (FCA audit retention requirements), but this exemption must be formally confirmed by NorthBridge's DPO and recorded in the ROPA before the WORM architecture is committed. |
| **Why this blocks Gate 3** | This is an architectural decision. WORM is irreversible. If the DPO later determines that the Art 17(3)(b) exemption does not apply, or applies only to a subset of records, the storage architecture will require redesign after build. |
| **Resolution** | NorthBridge's DPO must confirm in writing that: (a) FCA audit retention requirements constitute a legal obligation under Art 17(3)(b), (b) the scope of that obligation covers all data types stored in the WORM layer, (c) the retention duration (7 years proposed) is the minimum necessary. Written confirmation must be provided to Vitruvius before ADR-006 WORM configuration is finalised. |
| **Escalation if unresolved** | Gate 3 remains BLOCKED. ADR-006 WORM architecture cannot be committed. |

---

### BLOCK-03 — UK GDPR Art 22 / ISO 42001 §6.2: AI Impact Assessment Not Initiated

| Field | Detail |
|-------|--------|
| **Framework** | UK GDPR Art 22(2) / ISO 42001 §6.2 |
| **Finding** | The lawful basis for automated credit decision-making under Art 22 has not been formally documented. Separately, ISO 42001 requires an AI impact assessment for systems making decisions with significant individual consequences. Neither has been initiated. |
| **Why this blocks Gate 3** | Art 22(2) lawful basis must be documented in the ROPA before processing commences. The ISO 42001 impact assessment may identify design changes. Both must be in progress before the build phase to avoid retrospective rework. |
| **Resolution** | NorthBridge's DPO must: (a) document the Art 22(2)(a) lawful basis in the ROPA, (b) confirm the lawful basis is communicated in the applicant privacy notice. NorthBridge's AI governance lead (or DPO) must initiate the ISO 42001 AI impact assessment with a defined completion date. Both actions must be confirmed in writing before Gate 3 closes. |
| **Escalation if unresolved** | Gate 3 remains BLOCKED. |

---

## CONDITIONS LOG (NON-BLOCKING)

| ID | Framework | Item | Resolution Deadline |
|----|-----------|------|-------------------|
| C-01 | ISO 27001 A.5 | NorthBridge ISMS policy scope confirmation | Before production hardening gate |
| C-02 | ISO 27001 A.10 | Event Hubs CMK — risk acceptance or implementation | Before production hardening gate |
| C-03 | ISO 27001 A.15 | AISP formal supplier security assessment | Before AISP integration activated |
| C-04 | ISO 27001 A.16 | Incident response playbook | Before production hardening gate |
| C-05 | ISO 27001 A.17 | RTO/RPO formally defined | Before production hardening gate |
| C-06 | ISO 42001 §5.2 | AI policy document | Before production go-live |
| C-07 | ISO 42001 §6.1 | AI risk register | Before model training commences |
| C-08 | ISO 42001 §8.5 | Model validation methodology + fairness testing protocol | Before model training commences |
| C-09 | ISO 42001 §10.1 | Model retraining schedule defined | Before MVP go-live |
| C-10 | FCA SYSC 6.3 | NorthBridge IBS register updated to include this platform | Before production deployment |
| C-11 | FCA SYSC 6.3 | Impact tolerances defined | Before production deployment |
| C-12 | FCA Consumer Duty | OpenAI rationale prompt template signed off by compliance officer | Before OpenAI endpoint activated in production |
| C-13 | FCA Consumer Duty | Portal privacy notice updated for AI-assisted credit decisioning | Before production go-live |
| C-14 | UK GDPR Art 28 | Data Processing Agreement executed with AISP | Before AISP integration activated |

---

## ITEMS CONFIRMED GREEN BY ARCHITECTURE REVIEW

The following controls are assessed as met by the Vitruvius architecture:

- ISO 27001 A.8 Asset classification (CAF tags, IaC inventory)
- ISO 27001 A.9 Access control (Managed Identity, RBAC, Bastion)
- ISO 27001 A.10 Cryptography in transit (TLS 1.2, private endpoints)
- ISO 27001 A.13 Communications security (private endpoints, VNet segmentation)
- ISO 27001 A.14 Secure development (Bicep AVM, CI/CD gates)
- ISO 27001 A.18 Compliance alignment (CAF naming, FCA scope tags)
- ISO 42001 §8.4 Model transparency (SHAP, model cards, gradient boosting)
- ISO 42001 §8.6 AI documentation (model cards, prompt versioning, audit trail)
- ISO 42001 §9.1 Drift monitoring (AML drift monitor, PSI alerting)
- FCA Consumer Duty Chapter 4 Products and services outcome
- FCA Consumer Duty Human review pathway (underwriter queue, override audit)
- NCSC CAF A2 Risk management (private endpoints, Zero Trust, no public surface)
- NCSC CAF A3 Asset management (IaC inventory)
- NCSC CAF B1–B5 Technical protection controls
- NCSC CAF C1 Security monitoring (Log Analytics, Monitor alerts)
- UK GDPR Art 6 Lawful basis — credit data (contractual necessity assumed confirmed)
- UK GDPR Art 5(1)(b) Purpose limitation (re-scoring only)

---

## GATE 3 RECOMMENDATION

Gate 3 is **BLOCKED** pending resolution of BLOCK-01, BLOCK-02, and BLOCK-03. These are not architectural weaknesses — the design is substantively sound. They are process and legal obligations that must be initiated by NorthBridge's DPO and AI governance lead before the build phase commits the architecture decisions that those obligations constrain.

**Recommended path to Gate 3 clearance:**

1. NorthBridge DPO initiates DPIA and confirms in writing (BLOCK-01)
2. NorthBridge DPO confirms Art 17(3)(b) exemption for WORM audit records in writing (BLOCK-02)
3. NorthBridge DPO documents Art 22(2)(a) lawful basis in ROPA; AI governance lead initiates ISO 42001 impact assessment (BLOCK-03)
4. Security architect (human gate) reviews this pre-flight report and the ADR/HLD together
5. Security architect approves or escalates — Gate 3 granted

Once BLOCK-01 through BLOCK-03 are resolved in writing, Gate 3 can be granted and Vulcan may commence build.

---

*Issued by: Themis — Compliance & QA Agent, Talastron Kinetic AI*
*Engagement ID: TKA-NB-20260702-001*
*Talastron BMAD Pipeline: Stage 3 of 5 — Audit (Pre-Flight Complete)*
*This report is binding. Findings are not advisory.*