ARCHITECTURE REVIEW AND PROJECT INTAKE PROCEDURE

Intake · Review · Threat Model · Pre-Production · Handoff · Go-Live Risk Acceptance

Table of Contents

1. Purpose and Scope
2. Roles and Responsibilities
3. The Five-Phase Engagement Model
4. Who Needs a Review, and Who Doesn’t
5. Phase 1, Intake
6. Phase 2, Architecture Review and Threat Model
7. Phase 3, Build-Time Engagement
8. Phase 4, Pre-Production Security Review
9. Phase 5, Production Handoff and Go-Live
10. Required Diagrams
11. Templates
12. Metrics
13. Regulatory and Framework Alignment Summary
14. Pre-Approved Architecture Patterns
15. Document Control

1. Purpose and Scope

The Operating Model makes Engineering project engagement a core CERG delivery model. The RMF Phase 3 describes concept, design, build, pre-production, and production handoff outputs. Until this procedure, the intake forms, review checklists, threat modeling guidance, signoff criteria, and handoff packages those phases require existed implicitly.

This procedure defines how a project enters CERG attention, how Engineering reviews it, how Risk threat-models it, how findings flow to remediation or risk acceptance, and how the system enters production with the right documentation, baselines, monitoring, and accepted exceptions.

The standalone CERG-TMPL-AR-001 is the canonical front-door intake form for Phase 1. This procedure remains authoritative for the Phase 2 architecture review record, Phase 4 pre-production security review record, Phase 5 production handoff package, and go-live risk acceptance packet.

Engineering’s Job Is to Be in the Room Early

Architecture review is not a gate that bolts security onto a project at the end. It is the discipline of having Engineering in the design conversation early enough to change the design cheaply. A review that consistently surfaces “we have to redo the data flow now” is a review that came too late.

2. Roles and Responsibilities

3. The Five-Phase Engagement Model

CERG engagement with a project follows five phases. Not every project hits every phase, Section 4 names the carve-outs.

1. Intake, register the project; classify scope; determine review depth.
2. Architecture Review and Threat Model, design-stage review; threats and controls aligned to CERG-GOV-CB-001.
3. Build-Time Engagement, secure SDLC checks, IaC review, baseline conformance.
4. Pre-Production Security Review, readiness against the review findings, baselines, monitoring, and recovery.
5. Production Handoff and Go-Live, handoff package complete, risk acceptances approved, asset added to inventory and recurring controls.

4. Who Needs a Review: and Who Doesn’t

Reviewing every Power App or low-code workflow is how Engineering loses a quarter to busywork. Waving them all through is how Shadow IT eats the enterprise. CERG’s answer is: review the platform once, then trust the guardrails the platform enforces.

4.1 Mandatory Review

CERG Architecture Review is mandatory for projects that meet any of the following:

• Introduces a new IaaS / PaaS / cloud account, subscription, or project.
• Introduces a new SaaS service (any tier) handling business data.
• Touches OT / BES Cyber Systems or the IT/OT boundary (per CERG-STD-OT-001).
• Handles CUI (storage, processing, transmission) or changes the CUI boundary.
• Handles SOX-relevant financial data or process flows.
• Introduces or changes a third-party network connection.
• Modifies the production identity provider, federation, or PAM topology.
• Introduces a new authentication path to a system holding Restricted data.
• Crosses a trust boundary (network, identity, tenant, region, organization).
• Introduces a new data classification or regulatory scope into the environment.

4.2 Lightweight Review (Engineering Self-Service)

A lightweight, self-service review pattern (intake form + checklist + Engineering sign-off without full Phase 2) is acceptable for projects that:

• Reuse an already-reviewed pattern (e.g., new microservice on an already-reviewed Kubernetes cluster).
• Add capacity to an already-reviewed system.
• Use a pre-approved IaC module or service catalog template.

4.3 Citizen-Development Carve-Out

Citizen-development platforms (Power Platform, low-code app builders, business-managed automation) are not reviewed per app. They are reviewed once, at platform onboarding, with the assessment focused on the platform’s guardrails, then trusted to police the apps that run on it.

Apps built on the platform are governed by these guardrails. Where an app needs to step outside the guardrails (e.g., a new connector, an unusual data classification), it triggers Mandatory Review per Section 4.1.

The Test

If a citizen-development app cannot do anything outside the platform’s guardrails, CERG does not need to review it. If a platform’s guardrails are weaker than CERG’s standards, the platform is unsuitable for the data classification it’s hosting. Apps get reviewed only when they need to step outside the boundary.

4.4 What Does Not Need CERG Review

• Pure UX or visual changes to an existing system that don’t touch authentication, data classification, scope, or interfaces.
• Routine patching covered by CERG-PRC-VM-001.
• Routine configuration changes within the DISH-conformant pattern that don’t change trust boundaries.

4.5 Approved Pattern Register

Lightweight review depends on knowing which patterns are already approved. Engineering maintains an Approved Pattern Register as part of the architecture review record set. A pattern may be a reference architecture, IaC module, landing-zone template, CI/CD pipeline profile, SaaS configuration pattern, citizen-development guardrail set, or service-catalog template.

Each approved pattern records:

A project claiming lightweight review must cite the approved pattern it reuses and confirm it stays inside the pattern’s approved scope. If the project changes the pattern, extends it to a higher data classification, crosses a new trust boundary, or disables a required guardrail, it becomes Mandatory Review.

5. Phase 1: Intake

Intake is fast (< 5 business days) and produces a Scope Determination that drives every subsequent phase.

5.1 Security Project Intake Form (Template)

Use CERG-TMPL-AR-001 for the authoritative Phase 1 intake form. The structure below is retained as the procedure-level minimum content model and for adopters embedding intake directly into a ticketing system.

SECURITY PROJECT INTAKE - AR-YYYY-NNNN

A. PROJECT IDENTITY
   Project Name             :
   Sponsor (named role)     :
   Technical Lead           :
   Business Outcome         :
   Target Production Date   :

B. SCOPE
   Data Classifications Handled : Public / Internal / Restricted / CUI / BCSI
   Regulatory Scope             : None / CUI / BES / SOX (multi-select)
   Operating Units Impacted     :
   Environments                 : IT / Cloud / SaaS / OT / Hybrid
   Geographies                  : (countries; flag non-US access)
   Trust Boundaries Crossed     : (network / identity / tenant / org)

C. TECHNOLOGY
   New SaaS introduced?         : Y/N - name(s) - vendor(s)
   New cloud account/sub/proj?  : Y/N
   New OT touch / IT/OT bridge? : Y/N
   New external connection?     : Y/N
   New identity / federation?   : Y/N

D. THIRD PARTIES
   Vendors involved             : list
   Vendor tier (per TPRM)       :
   International access?        : Y/N - countries

E. CHANGE CONTEXT
   New build / migrate / retire / extend
   Existing CERG-tracked asset IDs (if extension)

F. INITIAL SECURITY CONCERNS (from project team)
   What worries us most         :
   What we know is unresolved   :

G. ASKS
   What CERG help do we need at design stage?

5.2 Scope Determination Output

The Intake reviewer (CERG Engineering) determines:

• Review path: Mandatory (Phase 2 full), Lightweight (self-service checklist), or Out of Scope.
• Overlay reviewers required: CUI, BES, SOX, OT, each named by CERG-GOV-CB-001.
• Threat modeling required: Y/N (default Y for Mandatory; conditional for Lightweight).
• TPRM engagement required: Y/N (default Y if any vendor is new or tier > business default).
• Estimated Phase 2–5 effort and target dates.

A Scope Determination is recorded against the project and visible to the team within five business days.

5.3 Review Path and SLC Tier Crosswalk

The review path determines how much review is required. The SLC tier determines the response clock published to the business in CERG-GOV-SLC-001. Intake records both values.

Where the review path and SLC tier appear to disagree, the Engineering Pillar Leader records the rationale. Regulated scope, new trust boundaries, and Restricted-data placement always bias upward.

6. Phase 2: Architecture Review and Threat Model

6.1 Architecture Review Checklist

The reviewer works through the checklist below; findings are recorded with severity and routed per CERG-PRC-RM-001.

6.2 Threat Model

The threat model is owned by CERG Risk in collaboration with the project. It uses STRIDE as the default decomposition for IT and a STRIDE-LM (with Lateral Movement) variant for OT. The format is a short Markdown document with the following structure:

THREAT MODEL - <Project Name>            AR-YYYY-NNNN - TM-001

1. ASSETS AND DATA - what's worth protecting, with classification
2. ACTORS AND ENTRY POINTS - humans, machines, external services
3. TRUST BOUNDARIES - drawn on the diagram; named in text
4. THREATS BY BOUNDARY - STRIDE per boundary; OT add Lateral Movement
5. EXISTING CONTROLS - what mitigates each threat
6. RESIDUAL - what remains, mapped to risk register entries
7. ATTACK SIMULATION CANDIDATES - for purple / red engagements (PRC-AV-001)

The Threat Model Earns Its Keep When It Changes the Design

A threat model that documents what was already decided is paperwork. A threat model that surfaces a control the design missed, a missing boundary, a misplaced trust, is the reason the review exists.

6.3 Phase 2 SLA

Phase 2 review (Architecture Review and Threat Model) follows the SLC tier assigned at intake: Tier 1 within 10 business days, Tier 2 within 7 business days, and Tier 3 within 5 business days where Phase 2 is required. Extensions may be granted by the Engineering Pillar Leader for complex systems (e.g., multi-cloud, OT-integrated, or CUI-scope systems with novel architecture). The project team is notified of any extension with rationale within the original SLA window.

6.4 Phase 2 Output

• Architecture Review record with status Approved / Approved-with-Conditions / Not Approved.
• Threat model attached.
• Findings in the risk register, scored.
• Build-time conditions for Phase 3.

7. Phase 3: Build-Time Engagement

Build-time engagement is the period between design approval and pre-production. CERG differentiates between routine and novel builds.

7.1 Routine vs. Novel Builds

The Engineering Pillar Leader determines whether a build is routine or novel based on the Phase 2 architecture review record and the project’s pipeline configuration.

7.2 CERG Review Checklist for Novel Builds

7.3 Acceptance Criteria for Build-Time Gates

7.4 Escalation for Build-Time Findings

Build-time findings are escalated within the development team first, then to CERG:

7.5 SLA for Build-Time Review

CERG completes novel-build review within 3 business days of notification. If the review cannot be completed within SLA, Engineering documents the delay, schedules the follow-up review, and notifies the project team. A build may proceed only if no blocking security gate has failed; any residual risk created by proceeding is routed through the risk acceptance process. Engineering does not accept business risk on behalf of the owner.

The artifacts produced during build include: IaC review for new modules and patterns; pipeline gates enforcing DISH baseline conformance, container image signing, SBOM generation, and exposure scanning; secrets checking; and conditional re-review if material design changes happen between Phase 2 and Phase 4.

8. Phase 4: Pre-Production Security Review

Pre-Production review is a focused, time-boxed readiness check. It produces a Pre-Production Security Review Record.

8.1 Pre-Production Checklist

8.2 Phase 4 SLA

Pre-Production Security Review is completed within 5 business days of the project team submitting the Pre-Production checklist evidence. Extensions may be granted by the Risk Pillar Leader where evidence review requires additional subject matter expertise.

8.3 Outcome

• Ready: go-live disposition in Phase 5.
• Ready-with-Risk-Acceptance: outstanding findings have risk register entries with approved exceptions per CERG-PRC-RM-001 §7.
• Not Ready: go-live blocked until specific items close.

9. Phase 5: Production Handoff and Go-Live

9.1 Production Handoff Package

The handoff package is the single artifact that goes into the asset’s record. It is a Markdown bundle with the contents below.

PRODUCTION HANDOFF PACKAGE - <System Name>     AR-YYYY-NNNN - PHP-001

1. SYSTEM IDENTITY
   Asset ID(s)  · Tier · Owners · Regulatory scope

2. CERG REVIEW RECORD
   Phase 1 Intake reference
   Phase 2 Architecture Review record (link)
   Phase 2 Threat Model (link)
   Phase 3 build conditions cleared (yes/no)
   Phase 4 Pre-Production record (link)

3. CONTROL POSTURE AT GO-LIVE
   Control-by-control state per [CERG-GOV-CB-001](../governance/CERG-GOV-CB-001_Unified_Control_Baseline.md) (Implemented / Partial / Inherited / Planned / Risk Accepted / N/A)
   Inheritance Evidence Packages on file (cloud / SaaS providers)

4. EVIDENCE POINTERS
   DISH scan output (latest)
   Exposure scan / pipeline output (latest)
   Identity / detection / logging configuration
   Backup configuration and first restoration test plan

5. RISK ACCEPTANCES AT GO-LIVE
   Exception IDs and approvers
   Treatment plans and expiration dates

6. ONGOING CONTROL OBLIGATIONS
   Recurring controls (scan cadence, recert cadence, restoration test cadence)
   Owners for each recurring control

7. RUN-BOOK AND ON-CALL
   References

8. SIGN-OFFS
   Engineering Reviewer
   Risk Reviewer
   Governance (overlay) Reviewer(s) - CUI / BES / SOX as applicable
   Engineering Pillar Leader
   CISO (if High / Critical risk acceptance)
   Business Owner

9.2 Go-Live Risk Acceptance Packet

A separate packet is produced only if go-live ships with one or more risk acceptances. It is the document the Business Owner and required approvers sign per the canonical authority table.

GO-LIVE RISK ACCEPTANCE PACKET - <System Name>     AR-YYYY-NNNN - GLR-001

Each accepted risk:
   - Risk Statement (per [CERG-TMPL-RM-001](../templates/CERG-TMPL-RM-001_Risk_Register_Templates_and_Reporting.md))
   - Linked control(s)
   - Compensating controls in place at go-live
   - Residual score and band
   - Expiration / re-review date
   - Treatment plan that retires the acceptance
   - Approver (per PRC-RM-001 §8)

Aggregate:
   - Combined residual score
   - Top three watch-list items
   - First post-go-live review date (≤ 90 days for Critical / High)

9.3 Phase 5 SLA

Production Handoff and Go-Live is completed within 3 business days of Phase 4 Ready disposition. The handoff package is the gate; go-live proceeds when the package is complete and signed.

9.4 Post-Go-Live Watch Period

• Critical / High risk acceptances trigger a post-go-live watch period of ≤ 90 days with a scheduled re-review.
• Detection telemetry is reviewed at 30 days for unexpected behavior tied to the accepted risk.
• Findings from the watch period feed back into the risk register and, where appropriate, the threat model.

9.5 Dispute and Appeal Process

If a project team disagrees with a finding, disposition, or outcome from any phase of the architecture review, the following appeal path is available.

Appeal Triggers

An appeal may be filed for: - A finding the project team believes is inaccurate, inapplicable, or overstated - A “Not Approved” disposition on a Phase 2 review - A “Not Ready” disposition on a Phase 4 pre-production review - A go-live condition the project team believes is unreasonable or infeasible

Appeal Process

Criteria for Overturning a Decision

A decision may be overturned if: - New or overlooked evidence demonstrates the finding is inapplicable - The project team proposes an alternative compensating control that achieves equivalent or superior risk reduction - The original decision was based on a misinterpretation of a standard or control requirement - The business impact of the decision is disproportionate to the risk it addresses

Documentation

Every appeal is documented in the review record, including: the appealed finding or disposition, the appellant’s rationale, the resolution, and the final decision-maker. Appeal outcomes inform program improvement per CERG-PRC-LL-001.

10. Required Diagrams

Every Mandatory Review delivers the diagram set below. Diagrams are produced in a tool that exports to durable formats; the latest version lives with the review record.

Where a diagram is implicit (e.g., a pure SaaS service has no on-prem network), the review record notes “Not Applicable” with rationale rather than omitting silently.

11. Templates

Architecture review uses one standalone intake template and several procedure-owned record patterns. Authority is split as follows:

A completed CERG-TMPL-AR-001 is not evidence that Phase 2, Phase 4, or Phase 5 has been completed. It is the intake and routing record that starts the chain.

12. Metrics

Baseline Establishment

Where a metric is marked “Baseline to be established in first year of operation,” the CERG Risk Pillar collects 12 months of data and proposes Green/Amber/Red thresholds at the next annual review. Prior to baseline, the metric is reported without RAG coloring.

13. Regulatory and Framework Alignment Summary

14. Pre-Approved Architecture Patterns

Good governance makes projects faster because teams can design correctly before vendor selection. The patterns below are pre-approved for architecture review at the “Light-Touch” tier if the described conditions are met. Engineering signs off; Governance and Risk are not required to engage unless the project exceeds the pattern’s boundaries.

Common exceptions across patterns:

Governance principle: Pre-approved patterns reduce review time by eliminating the discovery phase. If a project fits a pattern exactly, Engineering signs off and the project proceeds. If it deviates in any material way, it escalates to the review tier specified by the deviation. Patterns are reviewed annually and updated when standards change.

15. Document Control

Revision History

Review Triggers

• Change to architecture review intake, routing, or SLC tiers.
• Change to the standalone intake template or procedure-owned review record structure.
• Change to go-live risk acceptance authority.
• Audit, assessment, or tabletop finding related to project review evidence.

Related Documents

• CERG-TMPL-AR-001 - Architecture and Project Intake Form
• CERG-PRC-TM-001 - Threat Modeling Procedure
• CERG-PRC-RM-001 - Risk Register and Exception Process
• CERG-PRC-TPRM-001 - Third Party and Supply Chain Risk Procedure

Appendix A. Worked Example: CloudApp Migration

Purpose

This appendix walks a fictitious project — “CloudApp Migration” — through all five phases of the architecture review process. It shows what each artifact looks like when populated, so first-time adopters have a concrete reference.

A.1 Scenario

Profile: Contoso Energy Solutions, a mid-market utility ($1.2B revenue). NERC-CIP Low impact, SOX ITGC scope.

Project: Migrate the internal billing application (“CloudApp”) from on-premises to AWS. CloudApp processes customer billing data (Internal classification), interfaces with the financial ERP (SOX-scoped), and exposes a REST API to an external collections vendor.

Team: 1 Cloud Security Engineer (reviewer), 1 Risk Analyst (threat model), 1 Governance Pillar Leader (SOX overlay), 1 Project Technical Lead, 1 Business Owner (CFO designee).

A.2 Completed Intake Form (Phase 1)

SECURITY PROJECT INTAKE - AR-2026-0001

A. PROJECT IDENTITY
   Project Name             : CloudApp Migration to AWS
   Sponsor (named role)     : CFO Designee (Business Owner)
   Technical Lead           : Sr. Cloud Engineer, IT Operations
   Business Outcome         : Reduce datacenter footprint, enable auto-scaling
   Target Production Date   : 2026-09-30

B. SCOPE
   Data Classifications Handled : Internal (billing records)
   Regulatory Scope             : SOX (via ERP integration)
   Operating Units Impacted     : Finance, IT Operations
   Environments                 : Cloud (AWS)
   Geographies                  : US only
   Trust Boundaries Crossed     : Network (on-prem to cloud), Identity (IdP federation), Organization (vendor API)

C. TECHNOLOGY
   New SaaS introduced?         : Y - Twilio SendGrid (transactional email vendor) - tier assessment needed
   New cloud account/sub/proj?  : Y - new AWS production account
   New OT touch / IT/OT bridge? : N
   New external connection?     : Y - collections vendor API (Tier 2 per TPRM)
   New identity / federation?   : Y - AWS IAM Identity Center federation with Azure AD

D. THIRD PARTIES
   Vendors involved             : AWS, Twilio SendGrid, Collections Vendor (ABC Collect Inc.)
   Vendor tier (per TPRM)       : AWS = Tier 1, SendGrid = Tier 2, ABC Collect = Tier 2
   International access?        : N

E. CHANGE CONTEXT
   New build / migrate / retire / extend : Migrate + Extend (vendor API integration is new)
   Existing CERG-tracked asset IDs       : On-prem billing server (ASSET-00101)

F. INITIAL SECURITY CONCERNS (from project team)
   What worries us most         : SOX evidence continuity during migration; vendor API authentication
   What we know is unresolved   : ERP integration will use a private link; encryption cert renewal timeline

G. ASKS
   What CERG help do we need at design stage? : VPC design review, identity federation pattern, SOX evidence requirements

A.3 Scope Determination Output

A.4 Architecture Review Record (Phase 2)

Status: Approved-with-Conditions

Conditions for Phase 2 approval: - High findings (F01, F02, F05) must be remediated before Phase 4 pre-production review - Medium findings (F03, F04) must have treatment plan with owner and target date by go-live

A.5 Threat Model Record (Phase 2)

THREAT MODEL - CloudApp Migration               AR-2026-0001 - TM-001

1. ASSETS AND DATA
   - Customer billing records (Internal classification)
   - ERP financial transaction data (SOX-scoped)
   - AWS IAM roles, KMS keys, CloudTrail audit logs

2. ACTORS AND ENTRY POINTS
   - Internal users (Finance team) via Azure AD SSO
   - Collections vendor (ABC Collect) via REST API + API key
   - AWS managed services (RDS, DynamoDB, S3) - provider trust model

3. TRUST BOUNDARIES
   - On-premises Azure AD <-> AWS IAM Identity Center (identity boundary)
   - AWS VPC <-> On-premises ERP via AWS PrivateLink (network boundary)
   - CloudApp API <-> ABC Collect (external organizational boundary)

4. THREATS BY BOUNDARY
   Identity Boundary: [Spoofing] Compromised Azure AD account could assume AWS role
     -> Control: Conditional Access MFA, JIT elevation via PAM
   Network Boundary: [Tampering] Man-in-the-middle on PrivateLink connection
     -> Control: TLS 1.2 minimum, mutual TLS for ERP integration
   External Boundary: [Info Disclosure] ABC Collect API key leak could expose billing data
     -> Control: API key in Secrets Manager, IP whitelisting, rate limiting

5. EXISTING CONTROLS
   - Azure AD MFA for all internal users
   - AWS CloudTrail enabled across all accounts
   - AWS Config rules for baseline drift detection
   - VPCs with default-deny routing, limited egress

6. RESIDUAL RISKS (to risk register)
   - TM-R01: Vendor API compromise could allow data exfiltration [Medium]
   - TM-R02: SOX evidence chain depends on CloudTrail integrity [Low]

7. ATTACK SIMULATION CANDIDATES
   - Purple team: "Assume API key compromised — can attacker pivot to cloud control plane?"

A.6 Pre-Production Security Review (Phase 4)

Disposition: Ready-with-Risk-Acceptance

A.7 Production Handoff Summary (Phase 5)

A.8 Key Takeaways for First-Time Adopters

1. Start early. The intake form surfaced the SOX evidence concern on day one, which gave Governance time to map controls before go-live.
2. Threat modeling changed the design. The vendor API risk (TM-R01) prompted adding IP whitelisting and rate limiting that were not in the original architecture.
3. Pre-approved patterns reduce Phase 2 time. The AWS VPC landing-zone pattern was pre-approved; the team skipped the VPC design review and focused on application-layer controls.
4. Risk acceptance is not failure. The KMS key type acceptance was a deliberate decision after documented analysis — SOX auditibility was preserved via compensating controls.
5. Evidence continuity from day one. CloudTrail was configured before the first workload deployment, ensuring no gap in SOX evidence during migration.

Source: procedures/CERG-PRC-AR-001_Architecture_Review_and_Project_Intake_Procedure.md · Download .md · View on GitHub