Section 02

Scoping & System Decomposition

The quality of a TRA depends entirely on how well you scope it. This section covers context establishment, system decomposition techniques, asset classification, crown jewels analysis, data flow mapping, and trust boundary identification — the foundation that every other TRA phase builds on.

The Scoping Paradox

Scope too narrowly and you miss critical risks at integration points. Scope too broadly and the assessment becomes superficial. The techniques in this section help you find the right boundary — especially for modern cloud-native systems with dozens of managed services and third-party integrations.

Context Establishment

Before analyzing threats, you need three types of context. Each shapes the threat scenarios and risk analysis that follow.

Business Context

  • • What business function does the system support?
  • • What's the revenue/operational impact of downtime?
  • • Who are the users and what data do they provide?
  • • What are the contractual obligations (SLAs, DPAs)?
  • • What's the organization's risk appetite?

Regulatory Context

  • • Which regulations apply (PCI, HIPAA, GDPR, DORA)?
  • • What specific controls are mandated?
  • • What evidence must the TRA produce for auditors?
  • • Are there data residency requirements?
  • • What's the incident notification timeline?

Threat Context

  • • Which threat actors target this industry?
  • • What are current active campaigns?
  • • Has the organization been breached before?
  • • What's the geopolitical risk environment?
  • • What peer organizations have been compromised?

System Decomposition

Break the system into components that can be individually analyzed for threats. Start with the architecture diagram and decompose into layers.

System Decomposition Workflow

flowchart TD A["Architecture\nDiagram"] --> B["Component\nInventory"] B --> C["Data Flow\nMapping"] C --> D["Trust Boundary\nIdentification"] D --> E["Asset\nClassification"] E --> F["Crown Jewels\nAnalysis"] F --> G["Scope\nBoundary"] style A fill:#ff8800,stroke:#000,color:#000 style B fill:#22d3ee,stroke:#000,color:#000 style C fill:#a855f7,stroke:#000,color:#000 style D fill:#ec4899,stroke:#000,color:#000 style E fill:#ff8800,stroke:#000,color:#000 style F fill:#22d3ee,stroke:#000,color:#000 style G fill:#a855f7,stroke:#000,color:#000

Component Inventory Template

component-inventory.txt
text 
Component Inventory — [System Name]
Date: YYYY-MM-DD | Assessor: [Name]

COMPUTE LAYER
| Component          | Type        | Owner       | Internet-Facing | Data Sensitivity |
|--------------------|-------------|-------------|-----------------|------------------|
| API Gateway        | PaaS        | Platform    | Yes             | Transit only     |
| Auth Service       | Container   | Identity    | No (via GW)     | Credentials, PII |
| Order Service      | Container   | Commerce    | No (via GW)     | PII, Financial   |
| Worker Service     | Container   | Processing  | No              | Financial        |
| Admin Dashboard    | SPA         | Platform    | Yes (IP-locked) | All data types   |

DATA LAYER
| Component          | Type        | Encryption  | Backup          | Data Sensitivity |
|--------------------|-------------|-------------|-----------------|------------------|
| Customer DB        | Managed SQL | AES-256 TDE | Geo-redundant   | Confidential     |
| Transaction DB     | Managed SQL | AES-256 TDE | Geo-redundant   | Restricted       |
| Cache (Redis)      | Managed     | In-transit  | None            | Internal         |
| Object Storage     | Blob        | SSE-KMS     | Cross-region    | Confidential     |
| Message Queue      | Managed     | In-transit  | 7-day retention | Internal         |

IDENTITY & ACCESS
| Component          | Type        | Protocol    | MFA Required    | Federation       |
|--------------------|-------------|-------------|-----------------|------------------|
| Entra ID           | IdP         | OIDC/SAML   | Yes (all users) | Yes (B2B)        |
| Service Principals | Machine ID  | OAuth2 CC   | N/A             | N/A              |
| API Keys           | Static      | HMAC        | N/A             | N/A              |

NETWORK & EDGE
| Component          | Type        | DDoS Prot.  | WAF Rules       | TLS Version      |
|--------------------|-------------|-------------|-----------------|------------------|
| CDN / Front Door   | Edge        | Yes (L4/L7) | OWASP CRS 3.x   | 1.2+ only        |
| VNet / VPC         | Network     | N/A         | NSG/SG rules    | N/A              |
| Private Endpoints  | Network     | N/A         | N/A             | 1.2+ only        |

THIRD-PARTY INTEGRATIONS
| Provider           | Purpose     | Data Shared | Auth Method     | SLA              |
|--------------------|-------------|-------------|-----------------|------------------|
| Payment Processor  | Payments    | Card tokens | mTLS + API key  | 99.99%           |
| Email Service      | Notifications | Email addrs | API key        | 99.9%            |
| Analytics Platform | Telemetry   | Events      | API key         | 99.9%            |
Component Inventory — [System Name]
Date: YYYY-MM-DD | Assessor: [Name]

COMPUTE LAYER
| Component          | Type        | Owner       | Internet-Facing | Data Sensitivity |
|--------------------|-------------|-------------|-----------------|------------------|
| API Gateway        | PaaS        | Platform    | Yes             | Transit only     |
| Auth Service       | Container   | Identity    | No (via GW)     | Credentials, PII |
| Order Service      | Container   | Commerce    | No (via GW)     | PII, Financial   |
| Worker Service     | Container   | Processing  | No              | Financial        |
| Admin Dashboard    | SPA         | Platform    | Yes (IP-locked) | All data types   |

DATA LAYER
| Component          | Type        | Encryption  | Backup          | Data Sensitivity |
|--------------------|-------------|-------------|-----------------|------------------|
| Customer DB        | Managed SQL | AES-256 TDE | Geo-redundant   | Confidential     |
| Transaction DB     | Managed SQL | AES-256 TDE | Geo-redundant   | Restricted       |
| Cache (Redis)      | Managed     | In-transit  | None            | Internal         |
| Object Storage     | Blob        | SSE-KMS     | Cross-region    | Confidential     |
| Message Queue      | Managed     | In-transit  | 7-day retention | Internal         |

IDENTITY & ACCESS
| Component          | Type        | Protocol    | MFA Required    | Federation       |
|--------------------|-------------|-------------|-----------------|------------------|
| Entra ID           | IdP         | OIDC/SAML   | Yes (all users) | Yes (B2B)        |
| Service Principals | Machine ID  | OAuth2 CC   | N/A             | N/A              |
| API Keys           | Static      | HMAC        | N/A             | N/A              |

NETWORK & EDGE
| Component          | Type        | DDoS Prot.  | WAF Rules       | TLS Version      |
|--------------------|-------------|-------------|-----------------|------------------|
| CDN / Front Door   | Edge        | Yes (L4/L7) | OWASP CRS 3.x   | 1.2+ only        |
| VNet / VPC         | Network     | N/A         | NSG/SG rules    | N/A              |
| Private Endpoints  | Network     | N/A         | N/A             | 1.2+ only        |

THIRD-PARTY INTEGRATIONS
| Provider           | Purpose     | Data Shared | Auth Method     | SLA              |
|--------------------|-------------|-------------|-----------------|------------------|
| Payment Processor  | Payments    | Card tokens | mTLS + API key  | 99.99%           |
| Email Service      | Notifications | Email addrs | API key        | 99.9%            |
| Analytics Platform | Telemetry   | Events      | API key         | 99.9%            |

Asset Classification

Classify each asset by its CIA (Confidentiality, Integrity, Availability) impact to prioritize which components need the deepest threat analysis.

Rating Confidentiality Impact Integrity Impact Availability Impact
Critical Exposure causes regulatory breach, mass PII leak, or existential business damage Corruption causes financial loss, safety risk, or undetectable fraud Downtime causes revenue loss >$1M/hr, safety risk, or contractual breach
High Exposure affects significant customer data or competitive advantage Corruption affects financial reporting or customer trust Downtime causes significant revenue loss or customer impact
Medium Exposure of internal operational data with limited external impact Corruption causes operational disruption but is detectable and recoverable Downtime causes minor revenue impact, workarounds available
Low Public or non-sensitive data; exposure has minimal business impact Corruption has negligible impact; easily restored from backups Downtime has minimal impact; batch or background processes

Crown Jewels Analysis

Crown jewels are the assets whose compromise would cause maximum damage to the organization. Identify them first — they determine where to focus the deepest threat analysis.

Identifying Crown Jewels

  • Ask: "If this asset were compromised, would it make the news?"
  • Ask: "Could we survive losing this data/system for a week?"
  • Ask: "Does this asset enable access to other high-value targets?"
  • Ask: "Is this asset subject to regulatory notification requirements?"

Common Crown Jewels

  • • Customer PII databases (identity theft, regulatory fines)
  • • Payment processing systems (financial fraud)
  • • Authentication/identity infrastructure (total compromise)
  • • Encryption key management (loss of all confidentiality)
  • • CI/CD pipelines and signing keys (supply chain attack)
  • • Administrative access / break-glass accounts

Data Flow Mapping

Map how sensitive data enters, moves through, and exits the system. This directly informs trust boundary identification and threat scenario development.

Data Flow Mapping — SaaS Platform Example

flowchart LR subgraph ext[" External "] USER["End User\n(Browser)"] ADMIN["Admin\n(VPN)"] PARTNER["Partner\nAPI"] end subgraph edge[" Edge / DMZ "] CDN["CDN / WAF"] GW["API Gateway\n(AuthN/Rate Limit)"] end subgraph app[" Application Tier "] AUTH["Auth Service\n(OIDC)"] API["Business API\n(AuthZ)"] WORKER["Background\nWorker"] end subgraph data[" Data Tier "] DB["Customer DB\n(PII - Encrypted)"] BLOB["Document Store\n(SSE-KMS)"] QUEUE["Message Queue\n(Encrypted)"] end subgraph ext2[" External Services "] EMAIL["Email\nProvider"] PAY["Payment\nProcessor"] end USER -->|"HTTPS\n(PII in body)"| CDN ADMIN -->|"VPN + HTTPS"| GW PARTNER -->|"mTLS"| GW CDN --> GW GW -->|"JWT"| AUTH GW --> API API -->|"SQL/TLS\n(PII)"| DB API -->|"TLS\n(Documents)"| BLOB API --> QUEUE QUEUE --> WORKER WORKER -->|"API Key"| EMAIL WORKER -->|"mTLS\n(Card tokens)"| PAY style USER fill:#f87171,stroke:#000,color:#000 style ADMIN fill:#f87171,stroke:#000,color:#000 style PARTNER fill:#f87171,stroke:#000,color:#000 style CDN fill:#f59e0b,stroke:#000,color:#000 style GW fill:#f59e0b,stroke:#000,color:#000 style AUTH fill:#22d3ee,stroke:#000,color:#000 style API fill:#22d3ee,stroke:#000,color:#000 style WORKER fill:#22d3ee,stroke:#000,color:#000 style DB fill:#a855f7,stroke:#000,color:#000 style BLOB fill:#a855f7,stroke:#000,color:#000 style QUEUE fill:#a855f7,stroke:#000,color:#000 style EMAIL fill:#ec4899,stroke:#000,color:#000 style PAY fill:#ec4899,stroke:#000,color:#000

Trust Boundaries

Trust boundaries are where the level of trust changes between components. Every data flow crossing a trust boundary is a potential attack vector that needs controls.

High-Risk Trust Boundaries

  • • Internet → Edge (untrusted input crosses perimeter)
  • • Edge → Application (authentication/authorization enforcement)
  • • Application → Data (database access with sensitive data)
  • • Application → External API (data leaves organizational control)
  • • Admin plane → Production (privileged access to live systems)

Controls at Trust Boundaries

  • • Authentication — verify identity at every boundary crossing
  • • Authorization — enforce least privilege for the specific request
  • • Input validation — validate, sanitize, and encode at ingress
  • • Encryption — protect data in transit (TLS 1.2+) and at rest
  • • Logging — audit all cross-boundary access for detection

Scope Boundary Definition

Document what's in scope, what's out, and why. For cloud and SaaS environments, the shared responsibility model defines which risks you own versus which the provider manages.

scope-boundary-document.txt
text 
Scope Boundary Document — [Project Name] TRA

IN SCOPE
────────
• Application code and business logic (all microservices)
• API gateway configuration and WAF rules
• Database schemas, encryption, and access controls
• Authentication and authorization implementation
• CI/CD pipeline and deployment artifacts
• Third-party integrations (payment, email, analytics)
• Network segmentation and firewall rules
• Secrets management (Key Vault / Secrets Manager)
• Admin access and break-glass procedures

OUT OF SCOPE (with justification)
──────────────────────────────────
• Cloud provider physical security → Covered by SOC 2 Type II attestation
• Hypervisor security → Provider responsibility (PaaS model)
• Client device security → Separate endpoint security program
• DNS registrar security → Managed by IT operations team separately
• Office network → Not connected to production environment

INHERITED RISKS (accepted from shared responsibility)
─────────────────────────────────────────────────────
• Cloud provider availability → Documented RTO/RPO in provider SLA
• Managed database engine patches → Provider applies within SLA
• CDN/WAF rule accuracy → Shared; provider maintains CRS, we configure custom rules
• Identity provider availability → Entra ID SLA 99.99%; DR via break-glass accounts

THIRD-PARTY RISK ASSESSMENT STATUS
────────────────────────────────────
• Payment processor: SOC 2 + PCI DSS Level 1 on file (annual review)
• Email service: SOC 2 on file (annual review)
• Analytics: Privacy impact assessment completed (GDPR)
• CDN provider: SOC 2 + ISO 27001 on file
Scope Boundary Document — [Project Name] TRA

IN SCOPE
────────
• Application code and business logic (all microservices)
• API gateway configuration and WAF rules
• Database schemas, encryption, and access controls
• Authentication and authorization implementation
• CI/CD pipeline and deployment artifacts
• Third-party integrations (payment, email, analytics)
• Network segmentation and firewall rules
• Secrets management (Key Vault / Secrets Manager)
• Admin access and break-glass procedures

OUT OF SCOPE (with justification)
──────────────────────────────────
• Cloud provider physical security → Covered by SOC 2 Type II attestation
• Hypervisor security → Provider responsibility (PaaS model)
• Client device security → Separate endpoint security program
• DNS registrar security → Managed by IT operations team separately
• Office network → Not connected to production environment

INHERITED RISKS (accepted from shared responsibility)
─────────────────────────────────────────────────────
• Cloud provider availability → Documented RTO/RPO in provider SLA
• Managed database engine patches → Provider applies within SLA
• CDN/WAF rule accuracy → Shared; provider maintains CRS, we configure custom rules
• Identity provider availability → Entra ID SLA 99.99%; DR via break-glass accounts

THIRD-PARTY RISK ASSESSMENT STATUS
────────────────────────────────────
• Payment processor: SOC 2 + PCI DSS Level 1 on file (annual review)
• Email service: SOC 2 on file (annual review)
• Analytics: Privacy impact assessment completed (GDPR)
• CDN provider: SOC 2 + ISO 27001 on file

Cloud Shared Responsibility Gap

The most dangerous risks often live at the shared responsibility boundary — where the cloud provider's responsibility ends and yours begins. Misconfigurations in IAM, network rules, encryption settings, and logging are customer responsibility even on fully managed PaaS services. Always assess these explicitly.

Data Sensitivity Classification

PUBLIC

Marketing content, public APIs, open-source code

No impact from disclosure. Standard controls only.

INTERNAL

Internal docs, business metrics, system configs

Minor impact. Access control required.

CONFIDENTIAL

Customer PII, contracts, financial data, credentials

Significant impact. Encryption + strict access + audit logging.

RESTRICTED

Payment data, health records, encryption keys, admin creds

Severe impact. Maximum controls, need-to-know, regulatory notification.

Section Summary

Key Takeaways

  • • Establish business, regulatory, and threat context before analyzing threats
  • • Decompose systems into components, then classify each by CIA impact
  • • Crown jewels analysis focuses your effort on what matters most
  • • Every trust boundary crossing is a potential attack vector needing controls

Next Steps