3.2 Security & governance

You’ll want to rely on specific outputs from previous activities: value mapping (3.1), functional architecture (2.9), context mapping (2.5) and event storming (2.3). You’ll also need references to the security and compliance standards you feel are suitable to your project.

Before starting

Building security and compliance into the product before coding starts is cheaper, faster, and safer than bolting it on later. Postponing drives compliance debt that compounds; a production breach costs an average of $10M for U.S. firms, and firms take 200 days on average to even discover one.¹ Fortunately, you don’t need to be a security specialist to make good security decisions — you need a roadmap (an applicable standard), a tactical plan, and continuous monitoring. This activity delivers all three: a feature-by-feature security and compliance review that produces testable requirements, a threat model, and a traceable cross-reference from data types and regulations to your design artifacts.

The hard part is choosing which standards apply to your context — geography, market, customer segment, data types. The companion blog post When should you think about security? makes the case for early action. The zero trust architecture article and the forthcoming CRA overview go deeper on the two frameworks most likely to cover your needs.

Governance & security standards

You’ll need to know which standards apply to you — legally, geographically, and from a technology standpoint. Most projects narrow the list down to just a few. Your geographic market and your business partners set the bar. To launch in the EU, GDPR and CRA are effectively mandatory. In the U.S., NIST 800-53 is the de facto privacy baseline. PCI DSS applies whenever you touch card data.

Security and compliance isn’t just authentication, encryption, or intrusion monitoring. At a top level you’ll implement controls addressing product cybersecurity, vulnerability handling, operations concerns, reporting and awareness, and defect response. Nearly every standard touches all of these to some degree.

One standard to rule them all? There isn’t one — but CRA + NIST 800-207 (zero trust) covers most teams. CRA leans on ISO 27002, NIS2 and ETSI 303-645 so CRA compliance ticks a lot of boxes elsewhere. ZTA is a strong security posture with a side benefit: it forces everything to be infrastructure as code, part of the delivery pipeline. No more manual tweaks, no more mistakes.

Guide to security & governance

In this activity you’ll review the architectural components and features of your product and establish their security and compliance controls. Those controls roll into your roadmap. You’ll finish with the security and compliance features of your product defined in functional terms — feature statements with clear definitions and measurable success criteria.

We work from the prioritized value map to align security and compliance with upcoming delivery increments. For example, if we’re building IAM in this iteration but not yet doing online commerce, we can prioritize IAM security over PCI compliance.

Whatever security and compliance features we decide to implement, they’re features just like everything else. The product is incomplete — perhaps dangerously so — without them. Taking shortcuts here or deferring implementation is not appropriate. Early sprints will naturally build a security foundation; set expectations accordingly. Tough conversations will happen: “According to PCI requirements, we can’t actually process a credit card transaction without first building network security controls and a way to encrypt and protect customer PII. Unless we’re saying we don’t need PCI?”

This activity needs your whole team, including leadership, product management, and your customer. You’ll likely need to consult with your business’s legal counsel at least once to ensure regulatory and country-specific laws are adequately met.

Inputs

• Event maps for each user journey. A visual representation of commands, events, and state that describes how the system records facts that have happened in the past.
• Context map. A visual map of your bounded contexts that clearly indicates how each context depends upon and communicates with other contexts.
• Value map and feature prioritization. A very clear understanding of the business and customer value each feature creates, and its priority.
• Risk map. A clear representation of the risk and relative effort features carry.
• Functional architecture model. A view of your target state architecture that elaborates on specific technologies and design decisions.

Security & compliance features

You’ll itemize data types and identify each type’s sensitivity. You’ll also document each related feature, identifying the potential risk, its reference standard, and how it will be verified. The security & compliance cross reference template captures all of this.

A typical security feature entry looks like this:

Threat modeling

Have a consistent approach to threat modeling. Three popular models are STRIDE, PASTA, and OCTAVE. None are rocket science — they just provide a methodical, mature way to look at potential threats:

1. STRIDE (Microsoft, 1990s) — an acronym for six threat categories: Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, and Elevation of privilege. A systematic approach to identifying threats in software systems.¹⁴
2. PASTA — a risk-centric methodology developed by Tony Uceda Vélez and Marco M. Morana. Seven stages that align technical security requirements with business objectives, detailed in Risk Centric Threat Modeling.¹⁵
3. OCTAVE (Carnegie Mellon University’s SEI) — an organizational risk assessment framework rather than purely software-focused. Widely referenced.¹⁶

Throughout this activity, stay focused on designing security and privacy into the system. A few principles to keep front-and-center:

1. Know where all of your data is, including copies of data that might leak around your system.
2. Privacy by design means implementing data minimization, purpose limitation, and user consent mechanisms.
3. Think about defense-in-depth principles when designing your security architecture.¹⁷
4. Implement robust authentication and authorization. Most breaches come from theft of IAM data — more secure methods like passkeys give you an edge.
5. Apply encryption for data at rest and in transit. Protocols such as gRPC allow routine encryption in transit, making it a better default than straight-up JSON.
6. Design comprehensive logging for security events and good security information & event management (SIEM). This is required by most standards.
7. Simplify. Centralize controls to reduce your risk profile.

Process

This section covers how to conduct the discovery of your security and governance needs, and the tactical steps to turn them into concrete features in your product roadmap. Preparation is particularly important — your whole team needs to be prepped to discuss topics they probably aren’t familiar with.

Prepare

1. Identify your team and give them plenty of heads-up notice. You’ll likely need several working sessions, and you’ll probably have to expand the group (for instance, consulting legal counsel regarding policy, geographically relevant regulations, and legal obligations).
2. Make sure the team knows this is about planning your data governance and ensuring you meet necessary security and compliance needs.
3. Distribute background and research material ahead of time. Give the team time to get up to speed, and schedule a Q&A session to make sure everyone is clear on their roles. Provide:
   1. Relevant security background information. If you’re implementing online commerce, a brief backgrounder on PCI DSS. If you plan to do business in Europe, a summary of key GDPR responsibilities.
   2. A draft security plan or Q&A document to start from. In draft form:
      1. A list of all data types in your system (customer PII, financial data, intellectual property, etc).
      2. Interfaces and APIs (your context map), including external service APIs.
      3. A list of regulatory requirements and standards that might affect the organization.
      4. Suggested data formats, protocols and transport layers, encryption methods, approach for secret storage, and other technical details where available.
4. Organize your working sessions. Plan for multiple sessions, with time in between for research into tough questions (and reaching out to leadership and legal counsel on specific policy decisions). I like two-hour working sessions with at least a few days in between.
5. Review chapter 2.8 Delivery processes & tools for additional context around security planning.

The NIST Cybersecurity Framework Quick Start Guide provides useful templates, step-by-step implementation guidance, and self-assessment tools. There is a lot there, but it’s a great resource.¹⁸

Execute

1. Data classification exercise. Identify all data types and sources, and classify each based on sensitivity, how the data flows, and how long you need to retain it.
   1. Identify all data types in your system (customer PII, financial data, intellectual property, health records, commerce data).
   2. Classify data based on sensitivity levels to indicate how each element must be controlled (public, internal, confidential, restricted).
   3. Document data flows between components to show how information moves through your system (this should already be part of your context map — annotate and keep it up to date).
   4. Define retention periods for each data type, so you know how long you need to keep it, and when you need to destroy it.
2. Perform threat modeling. Use structured threat modeling — STRIDE, PASTA or OCTAVE — on top of your context map or your functional architecture model (from 2.9).
   1. Identify threats by systematically analyzing each feature and component for vulnerabilities.
   2. Rate risks to assess the likelihood and impact of each threat.
   3. Document attack vectors by detailing how attackers might exploit vulnerabilities.
3. Review regulatory requirements. Translate compliance obligations into specific requirements:
   1. Create a compliance matrix mapping which regulations apply to your product.
   2. Extract security controls from the standards by identifying specific security measures required by each regulation.
   3. Resolve conflicts by determining how to satisfy overlapping requirements.
   4. Document evidence needs by listing exactly what documentation or generated evidence will prove compliance after-the-fact. This is an essential input when deciding how to test your deliverable.
4. Incorporate other relevant industry standards. Leverage established frameworks:
   1. Review relevant standards like CRA, NIST 800-207 and ISO 27002.
   2. Select applicable controls appropriate to your risk profile.
   3. Adapt to your context by tailoring generic controls to your specific environment.
   4. Document your rationale by explaining why certain controls were selected or modified. Decisions will be questioned later — having a clear reminder saves time.
5. Consider customer expectations. Factor in market and customer requirements:
   1. Review customer contracts to identify security obligations to customers.
   2. Analyze RFP/RFI requirements or statements of work and note common security requirements in your industry.
   3. Review your documented SLAs to expose additional security-related business requirements.
6. Develop specific requirements. Transform analysis into actionable requirements:
   1. Use clear language to write specific, testable requirements in the form of use cases.
   2. Define clear verification methods, your key results, for your use cases.
   3. Review relevant event maps and, where appropriate, update them (or add new ones) to reflect changes to your system design.
   4. Document changes to your functional architecture wherever necessary.
   5. Review your value map, adding these new security features and prioritizing each appropriately.
   6. Itemize your security and compliance features. Create a canonical cross reference — you can use the security & compliance cross reference template as a starting point. This document correlates security or compliance needs with their respective requirements, designs, and use cases.

Outputs

• Revised use cases, key results, and system designs. A new set of features that define your security posture, integral to the design, no different from customer-facing features.
• Security & compliance cross reference. A document providing a cross-referenced catalogue of data sources and types, security features and compliance requirements.

Templates

• Security & compliance cross reference

Next activity

• 3.3 Identify product increment