PASTA Stage 1: Define Business Objectives
Establish what the application protects, why it matters, and what business impact
a compromise would have. This stage anchors the entire PASTA threat model to real
business value so that subsequent stages prioritize by actual organizational impact.
Supported Flags
Read ../../shared/schemas/flags.md for the full flag specification. Key behaviors:
| Flag |
Stage 1 Behavior |
--scope |
Default changed. Scans configs, docs, schemas, and API contracts to infer business purpose. |
--depth quick |
Business purpose from project metadata only. |
--depth standard |
Full analysis of configs, schemas, and code to infer objectives, compliance, and risk thresholds. |
--depth deep |
Standard + trace payment flows, PII handling, and regulatory indicators across the codebase. |
--depth expert |
Deep + formal risk tolerance matrix with quantified impact categories. |
--severity |
Not applicable at this stage (no vulnerability findings produced). |
Framework Context
Read ../../shared/frameworks/pasta.md, Stage 1 section. PASTA is SEQUENTIAL.
Stage 1 output feeds Stage 2. Do not skip this stage.
Prerequisites
None. This is the first stage. The analyst needs access to the application source
code, configuration files, and any available documentation.
Workflow
Step 1: Determine Scope
- Parse
--scope flag (default: changed).
- Resolve to a concrete file list.
- Prioritize:
README, package.json, pom.xml, .env.example, database
migrations, API routes, OpenAPI specs, Terraform/CloudFormation, docs/.
Step 2: Identify Business Purpose
- Core function: What does this application do? (e-commerce, SaaS, API, etc.)
- Users: Who uses it? Customers, employees, partners, public?
- Data handled: PII, financial, health, credentials, intellectual property?
- Revenue impact: Directly revenue-generating or supporting?
Step 3: Identify Compliance Requirements
Scan for indicators: PCI-DSS (payment processing, Stripe), HIPAA (health data,
FHIR), GDPR/CCPA (EU data, consent, deletion endpoints), SOX (audit trails),
SOC 2 (multi-tenant SaaS, data isolation).
Step 4: Define Risk Appetite
- Acceptable downtime: SLA requirements.
- Data sensitivity: Classify as public, internal, confidential, restricted.
- Blast radius: Systems and users affected if compromised.
- Recovery cost: Data loss vs. data exposure trade-offs.
Step 5: Document Business Context
Produce the Stage 1 output document that feeds Stage 2.
Analysis Checklist
- What is the worst business outcome if this application is fully compromised?
- What data, if exposed, would trigger regulatory notification requirements?
- What is the acceptable downtime for this service?
- Which business processes depend on this application's integrity?
- Who are the stakeholders impacted by a breach?
- Does the application handle payments, PII, health data, or other regulated data?
- Is this application internet-facing, internal, or both?
- What is the risk appetite -- startup-aggressive or enterprise-conservative?
Output Format
Stage 1 produces a Business Context Document. ID prefix: PASTA (e.g., PASTA-S1-001).
## PASTA Stage 1: Business Objectives
### Application Purpose
[1-2 sentence summary of what the application does and why it matters]
### Business-Critical Assets
| Asset | Type | Sensitivity | Impact if Compromised |
|-------|------|-------------|----------------------|
| ... | Data / Process / System | Public / Internal / Confidential / Restricted | ... |
### Compliance Requirements
| Regulation | Applicable | Evidence | Key Requirements |
|-----------|-----------|----------|-----------------|
| PCI-DSS | Yes/No/Unknown | [files/patterns] | [controls] |
| HIPAA / GDPR / SOX | ... | ... | ... |
### Risk Tolerance
| Category | Tolerance | Justification |
|----------|-----------|---------------|
| Downtime | [hours/minutes] | [SLA evidence] |
| Data exposure | [severity] | [data classification] |
| Financial loss | [threshold] | [revenue model] |
### Assumptions
[List assumptions made when business context was ambiguous]
Findings follow ../../shared/schemas/findings.md with:
metadata.tool: "pasta-objectives", metadata.framework: "pasta", metadata.category: "Stage-1"
Next Stage
Stage 2: Define Technical Scope (pasta-scope). Pass the Business Context
Document. Stage 2 maps the attack surface and builds DFDs focused on the assets
and processes identified here.
1---2name: pasta-objectives3description: This skill should be used when the user asks to "define business objectives", "identify business-critical assets", "determine risk appetite", or is running PASTA stage 1. Also triggers when the user asks about compliance requirements, acceptable risk thresholds, or business impact analysis in a threat modeling context. Part of the PASTA threat modeling methodology (Stage 1 of 7).4---56# PASTA Stage 1: Define Business Objectives78Establish what the application protects, why it matters, and what business impact9a compromise would have. This stage anchors the entire PASTA threat model to real10business value so that subsequent stages prioritize by actual organizational impact.1112## Supported Flags1314Read `../../shared/schemas/flags.md` for the full flag specification. Key behaviors:1516| Flag | Stage 1 Behavior |17|------|------------------|18| `--scope` | Default `changed`. Scans configs, docs, schemas, and API contracts to infer business purpose. |19| `--depth quick` | Business purpose from project metadata only. |20| `--depth standard` | Full analysis of configs, schemas, and code to infer objectives, compliance, and risk thresholds. |21| `--depth deep` | Standard + trace payment flows, PII handling, and regulatory indicators across the codebase. |22| `--depth expert` | Deep + formal risk tolerance matrix with quantified impact categories. |23| `--severity` | Not applicable at this stage (no vulnerability findings produced). |2425## Framework Context2627Read `../../shared/frameworks/pasta.md`, Stage 1 section. PASTA is SEQUENTIAL.28Stage 1 output feeds Stage 2. Do not skip this stage.2930## Prerequisites3132None. This is the first stage. The analyst needs access to the application source33code, configuration files, and any available documentation.3435## Workflow3637### Step 1: Determine Scope38391. Parse `--scope` flag (default: `changed`).402. Resolve to a concrete file list.413. Prioritize: `README`, `package.json`, `pom.xml`, `.env.example`, database42 migrations, API routes, OpenAPI specs, Terraform/CloudFormation, `docs/`.4344### Step 2: Identify Business Purpose45461. **Core function**: What does this application do? (e-commerce, SaaS, API, etc.)472. **Users**: Who uses it? Customers, employees, partners, public?483. **Data handled**: PII, financial, health, credentials, intellectual property?494. **Revenue impact**: Directly revenue-generating or supporting?5051### Step 3: Identify Compliance Requirements5253Scan for indicators: PCI-DSS (payment processing, Stripe), HIPAA (health data,54FHIR), GDPR/CCPA (EU data, consent, deletion endpoints), SOX (audit trails),55SOC 2 (multi-tenant SaaS, data isolation).5657### Step 4: Define Risk Appetite58591. **Acceptable downtime**: SLA requirements.602. **Data sensitivity**: Classify as public, internal, confidential, restricted.613. **Blast radius**: Systems and users affected if compromised.624. **Recovery cost**: Data loss vs. data exposure trade-offs.6364### Step 5: Document Business Context6566Produce the Stage 1 output document that feeds Stage 2.6768## Analysis Checklist69701. What is the worst business outcome if this application is fully compromised?712. What data, if exposed, would trigger regulatory notification requirements?723. What is the acceptable downtime for this service?734. Which business processes depend on this application's integrity?745. Who are the stakeholders impacted by a breach?756. Does the application handle payments, PII, health data, or other regulated data?767. Is this application internet-facing, internal, or both?778. What is the risk appetite -- startup-aggressive or enterprise-conservative?7879## Output Format8081Stage 1 produces a **Business Context Document**. ID prefix: **PASTA** (e.g., `PASTA-S1-001`).8283```84## PASTA Stage 1: Business Objectives8586### Application Purpose87[1-2 sentence summary of what the application does and why it matters]8889### Business-Critical Assets90| Asset | Type | Sensitivity | Impact if Compromised |91|-------|------|-------------|----------------------|92| ... | Data / Process / System | Public / Internal / Confidential / Restricted | ... |9394### Compliance Requirements95| Regulation | Applicable | Evidence | Key Requirements |96|-----------|-----------|----------|-----------------|97| PCI-DSS | Yes/No/Unknown | [files/patterns] | [controls] |98| HIPAA / GDPR / SOX | ... | ... | ... |99100### Risk Tolerance101| Category | Tolerance | Justification |102|----------|-----------|---------------|103| Downtime | [hours/minutes] | [SLA evidence] |104| Data exposure | [severity] | [data classification] |105| Financial loss | [threshold] | [revenue model] |106107### Assumptions108[List assumptions made when business context was ambiguous]109```110111Findings follow `../../shared/schemas/findings.md` with:112- `metadata.tool`: `"pasta-objectives"`, `metadata.framework`: `"pasta"`, `metadata.category`: `"Stage-1"`113114## Next Stage115116**Stage 2: Define Technical Scope** (`pasta-scope`). Pass the Business Context117Document. Stage 2 maps the attack surface and builds DFDs focused on the assets118and processes identified here.
florianbuetow