Chapter 7. Risk for Agile Teams

Security professionals live and breathe risk management. But developers, especially developers on an Agile team, can get happily through their day without thinking about risk much, if at all.

Let’s look at what’s involved in bringing these two different worlds—or ways of looking at the world—together.

Security Says, No

Before we get into how risk management is done, let’s take a quick detour to the purpose of risk management and security in general.

Security teams have a reputation for being the people who say “No” in many organizations. A project team may be ready to deliver a new feature, but are using an approach or a technology that the security team doesn’t understand, so it isn’t allowed to go out. The operations team needs a firewall change to support a new system, but the security team owns the firewalls and can’t coordinate the change in time, so the implementation of the system is blocked.

All of this is done in the name of risk management. Risk management is about enumerating and quantifying the unknown and attempting to control the risk. The easiest way to control the unknown and the risk is to prevent changes so that nothing can go wrong. However this fundamentally misses the point, and when tried in a fast-moving environment, results in a number of negative side effects to security overall.

Security should be about enabling the organization to carry out its goals in the most safe and secure manner possible. This means that an effective risk management process should be about enabling people in the organization to take appropriate risks in an informed manner. The key here being informed: risk management is not all about avoidance, but the mindful understanding, reduction, sharing, and acceptance of risk as appropriate.

Instead of saying “No,” security should be saying “Yes, but,” or even better “Yes, and,” and providing guidance and help to carry out the actions in the safest and most secure way possible.

But that aside, let’s look at how risk management is commonly understood.

Understanding Risks and Risk Management

Risk management is central to security and compliance, helping ensure that systems are safe from attack.

The security industry has over the last few decades gone to a lot of effort to define and standardize methods for understanding and controlling risks. Regulations like PCI DSS and SOX, and governance and control frameworks like NIST SP 800-53 and COBIT, expect you to follow a recognized and proven risk management approach, such as:

ISO 27005
NIST SP 800-30/39
OCTAVE
FAIR
AS/NZS 4360

These risk management methodologies are about dealing with uncertainties. All risk management approaches start with identifying, rating, and ranking risks to help you to get some control over uncertainty.

Risk ratings take into account the likelihood of something bad happening, and the potential costs that your organization could incur if it does happen. This is done by assigning a numeric rating (quantitative) or a relative high-medium-low priority (qualitative) to each risk.

According to ISO 31010, the international standard for risk assessment, there are 31 different risk assessment techniques that you could choose from. Formal risk assessment techniques can help you to make difficult trade-offs and answer questions like, how much should you spend trying to protect your system your data, your organization, and your customers from something that may or may not go wrong?

But even using formal methods, security risks in software can be difficult to evaluate. What is the negative cost of a fully exploited XSS vulnerability in one of your web applications? And what is the chance of it occurring? How should your product owner or program manager decide which risks need to be addressed, and in what priority?

Compliance requirements often dictate how these decisions will be made. For example, PCI DSS requires that all vulnerabilities with a certain risk rating must be remediated within specific time guidelines. Tools such as OWASP’s Top 10 Risk List can also help you to evaluate and decide how to deal with different security risks.

OWASP Top 10 Risk Management Tool

OWASP’s Top 10 Risk List identifies the most common and most serious software risks for web applications. This includes risks like injection, broken authentication and session management, and cross-site scripting. For each of these risks, it covers the following elements:

Threat agents: Which type of users to look out for.
Attack vectors and attack scenarios: What kind of attacks to expect.
Exploitability: How easy it is for attackers to exploit, and how widespread is the vulnerability.
Detectability: How easy it is for attackers to find.
Impacts: Technical and application-specific or business-specific impacts.

This information is a great first stop on your road to greater risk understanding and will help you to understand where to focus your training, design and coding, reviews, and testing effort.

Risk management is not static: it will change in response to threat intelligence, regulatory changes, and changes that you make to your system or your operations procedures. This is why regulations like PCI DSS also mandate regular risk reviews.

Risks and Threats

We introduced the concepts of risk and threats earlier in this book, and we’ll talk more about threats and how to deal with them in another chapter. Here we want to make clear the difference between threats and risks, and how they interplay:

Threats: What and who you have to protect your system/data/customers from, what could go wrong, and what harm could this cause to your system or the data. Threats are specific.
Risks: Your system’s exposure to threats (probability and costs), what you can/should do to reduce this exposure, and the cost trade-offs. Risks are abstract.

Security threats and risks are everywhere if you know where to look for them.

If your industry is under active attack, if your organization is holding a lot of valuable personal data or financial data, and if your application is popping with SQL injection and XSS vulnerabilities when you scan it, then you’re in a lot trouble, and you need to do something about it.

But if your organization might be under attack, and you don’t know what your threats are, and you aren’t testing your systems, and you don’t know what vulnerabilities you have or how serious they are, then you are probably in a lot more trouble. Sticking your head in the sand does not cause those risks or threats to disappear.

Everyone is under a range of threats today, across every industry, in every geography. You can’t pretend that you don’t have to worry about data security or software security because your organization is small or just a startup or you’re working in a legacy environment. That doesn’t cut it anymore.

As a starting point, you need to understand the threats that your organization and system face, and how serious they are. This is the goal of threat intelligence and threat assessment, which we explain in Chapter 8, Threat Assessments and Understanding Attacks.

Then you need to look at how well prepared your system and your organization are to meet these threats, or what you need to do to reduce the risks. That’s the point of this chapter.

What is important to regulators, your management, your customers, and other stakeholders is that you take a serious and consistent approach to identifying, assessing, communicating, and addressing risks that could impact the security of your systems.

Dealing with Risk

There are different strategies for handling risks:

Reducing: Implementing countermeasures or controls, compensating controls (such as activity auditing, or runtime IPS or application firewalls), plans to manage risks, tools, training, testing, and scanning
Avoiding: Deciding not to do something, disabling or simplifying a feature or an interface, and not using unsafe or unproven technology
Accepting: Recognizing that bad things will probably happen, and then preparing to deal with them: monitoring, incident response, and continuous delivery (proven ability to deploy patches quickly)
Sharing or transferring: Outsourcing to third parties like data center operators or cloud services providers or managed security service providers (MSSPs) to share risk; or taking on an insurance policy

The key thing to be aware of is that any given risk mitigation technique or control has a cost associated with it. That might be a financial cost, performance impact, delay in time to market, or loss of changeability or usability. We need to be sure that the approach we select aligns with the organization’s needs and priorities, and doesn’t hamper the organization beyond the value of what we are trying to protect.

Outsourcing Doesn’t Make Risks Go Away

Outsourcing responsibilities for coding, testing, or operations doesn’t make your risks go away.

Outsourcing to a third party can make good business sense, as well as help to reduce operational and security risks: a good example could be using an enterprise cloud services provider like AWS to host your application, rather than trying to set up your own secure data center. However, you are still responsible for understanding and managing these risks, as well as new ones that may arise from the act of outsourcing. Regulators and insurers will insist on this.

You need to be confident that whoever is doing work on your behalf is taking responsible steps to protect your data and your customer’s data, and has appropriate operational risk management and security capabilities in place.

If you have enough leverage (your organization is large enough, or the size of the deal is big enough), you can insist on specific requirements during contracting. Big and small firms should also do regular reviews on key service providers as part of their operational risk management programs.

One tool that can help you with this is a Structured Information Gathering (SIG) questionnaire , available from https://sharedassessments.org for a small fee, which will walk you through how to do a risk assessment of a service supplier. It asks organizations to describe their IT, privacy, security, and risk management controls. You can use it in RFP situations, as part of regular check-ups, or even as a self-assessment of your own controls.

The SIG guide is a standardized and comprehensive set of questions that is designed to help meet regulatory requirements and guidelines such as PCI DSS, FFIEC, NIST, and ISO. You can customize it to meet specific compliance or governance requirements. The SIG Lite is a smaller, simpler questionnaire that you can use for less critical suppliers or for initial risk assessments.

You can gain some confidence that you have mitigated specific risks by testing the system against vulnerabilities and other events that you anticipate. Traditionally, software development teams do this at point of release with penetration testing or some other kind of security review.

Leaving these checks until the end means that risk owners are often forced to choose between inadequate security solutions and not releasing on time. It’s this that results in security having a bad name in many circles, and results in unusable and insecure systems in the wild.

Modern Agile teams have to follow a different approach, where they integrate risk management directly into their design, development, testing, and deployment activities, and leverage automation and iteration and feedback loops to maintain a high level of confidence in the face of high-velocity delivery. They need to do all of this in ways that don’t slow them down or add unnecessary cost.

Making Risks Visible

Of course it isn’t possible to mitigate every risk. You need to have have a good understanding of what risks (the risks that you know about) you haven’t addressed yet or were only able to partially address.

On traditional software projects, this is done with a risk register maintained by the project manager, and by reporting the “residual risks,” those risks that reside in the system after deployment.

Modern teams can track security risks in several ways:

Continuously scanning infrastructure and code, including open source libraries and frameworks, for out-of-date packages and known vulnerabilities
Tracking vulnerabilities and metrics on how they are managed, as we described in Chapter 6, Agile Vulnerability Management
Measuring automated test coverage and code complexity in high-risk code areas
Watching for security stories and attacker stories in the backlog that have not been implemented
Measuring lead time for changes and MTTR (mean time to recovery) for problems in production, which tell you how fast the team can respond to a severe vulnerability or security breach
Tracking technical debt on the backlog as stories, or using automated code analysis platforms like SonarQube or Code Climate

Some Agile teams also maintain a risk register in the form of a risk backlog or a risk wall that lists risks that they’ve identified, their rating, and notes on how the team plans to deal with them. This risk backlog is managed the same way as the team’s story backlog: items are prioritized and scheduled depending on priority and cost.

The team’s progress working through the risk backlog can be measured in the same way that they measure their velocity delivering stories, and reported using tools like Risk Burndown Charts.¹

Accepting and Transferring Risks

There are some risks that you can’t manage effectively, at least not now, or that you may decide are not worth trying to minimize because you believe that they are unlikely to occur, or because they are so low impact that they won’t cause a significant cost to the organization if they do occur.

In these cases, you have a couple of choices:

Someone in the organization with the appropriate authority can accept the consequences of the risk, should it trigger. In Agile teams this could be a decision made by the Product Owner or the entire team together, with or without the security team or management involved.

It’s important to make sure that the whoever makes this decision has enough information to do it responsibly. And it is important to understand that accepting a risk doesn’t make the risk go away. Each time that you accept a risk, you are taking on a kind of debt, just like you do with financial debt, or technical debt; and never forget that debt accrues interest.

You and your management should be prepared to pay off this debt some day.

One way to prepare is by making sure that you have a good incident response capability in place and exercising it so that you know that you can deal with problems if they come up, something that we cover in Chapter 13, Operations and OpSec.
You can also transfer the risk or part of the risk on to another party, by outsourcing responsibilities to another organization that is better prepared to deal with risk (for example, outsourcing your data center facilities management to a high-quality cloud services provider), or you can take out insurance to cover some of your risk.

An insurance policy is not a get out of jail free card. Insurers will check to ensure that you’ve done a responsible job of reducing your and their risks to an acceptable minimum; and they will use these to determine premiums and deductibles, as well as to draw clear lines around what will and will not be covered.

Changing Contexts for Risks

If you decide to accept a risk with a system, then it is critical that you record that fact somewhere and review it regularly, especially in an Agile team.

Risks are not just static concepts. Risks are the manifestation of threats and vulnerabilities in the system. This means that the status, significance, and importance of risks will change over time; and in particular, they tend to change as the system changes.

In traditional risk management, this isn’t necessarily a hard problem to manage. If the system is only changed when significant projects are completed (e.g., say an annual basis), then the risk management process may only need to be redone once a year or so.

But with an Agile team continuously changing the system in response to new information, the context in which a risk is accepted can change dramatically in a fairly short time.

It is very difficult and therefore rare for traditional risk management processes to be managed at the same speed as an Agile team, which means that risk decisions are often made within the context of individual changes. However, risk accretes or compounds, and it can be difficult to model or catch this appropriately.

For example, one of us worked on a single sign-on system. The system had a bug in the password reset flow that at the end of the process logged you into the system without needing to type your password again.

This created a vulnerability, because someone following a link in an email and not having to enter the old password could potentially hijack an account. However the risk of somebody intercepting the email and exploiting it was deemed low, and the risk was accepted by the team and added to a backlog of risks.

Fast forward 12 months, and the same issue was rediscovered in a security test. However, now it was a much bigger deal, because in the preceding 12 months, the single sign-on system had been reused to provide login to a number of other sensitive systems.

When those new systems were added, one of the agreed security practices was that the sign-on would require a second factor, in this case a code from an OTP (one-time password) application, entered at login time in addition to the password. This requirement was implemented, and the system was considered acceptable.

However, the password-reset-bypass bug now also bypassed the two-factor authentication, which was a much more significant vulnerability.

The team was able to fix this issue and roll out the fix within hours of being identified. What they learned from this incident was that while the decision to accept the risk was appropriate for the initial context, it was not easy to recognize that this decision needed to be re-evaluated when they made other context-changing decisions such as enrolling new sensitive systems or adding the two-factor requirement.

Risk Management in Agile and DevOps

Agile development and DevOps practices cause problems for traditional risk management practices. We are in some fairly new territory without a clear set of rules. The community of risk management practitioners has not yet agreed on a methodology of risk management that is compatible with Agile, and as such we can find a number of culture clashes when trying to manage risk in a way that is acceptable to everyone within your organization, as well as to your auditors.

In particular, Agile practices are commonly perceived to introduce whole new kinds of risk.

Speed of Delivery

The biggest new risk is that the Agile focus on speed of delivery leads to a rate of change that traditional approaches to managing risks aren’t designed for.

Common change control practices, such as specified by ITIL or COBIT, are designed to deal with Waterfall projects that push large change sets a handful of times per year and cannot possibly keep up with continuous delivery or continuous deployment approaches.

Manual testing practices and quality gates, including penetration testing and compliance audits, are slow, intensive processes that can take weeks to assess a single build. These processes need a fundamental shift in thinking to cope with the speed of Agile delivery.

As such, risk practices tend to get left out, ignored, or bypassed for many Agile teams. This creates a new risk: that the baby is thrown out with the bathwater, that risk controls are put aside completely instead of replacing them with something that provides a similar, but simpler set of checks and balances at lower cost.

However, speed of delivery can also be an advantage in dealing with security risks.

Few organizations working in a traditional project delivery environment acknowledge that slow, closely managed deployments are themselves a source of risk, because changes involve so many people and so many moving parts, and because this forces emergency changes to bypass many of the control processes involved in order to get things done in time.

Agile teams make changes on a regular and repeated basis, meaning that the risk of any individual change affecting or damaging the system’s security properties is much reduced, while the team’s ability to revert or roll back a change is much increased. Fast-moving Agile teams can also quickly respond to risks, vulnerabilities, and issues when they recognize them.

Incremental Design and Refactoring

Traditional practices are highly reliant on development artifacts, such as written design specifications and models, detailed requirements, and so forth.

The traditional practices tend to assume that when changes are made to the system, these artifacts will be updated inline with the changes, enabling the risk management process to review changes to the system design for security vulnerabilities and risks, and propose mitigations or changes.

Agile methodologies focus on incremental and iterative design, meaning that the design of the system is not available to review before work starts, nor is there necessarily a set of artifacts that are updated with changes.

This approach increases the risk that teams will miss important compliance constraints or fail to anticipate security requirements in design and planning in favor of focusing on feature delivery, and it eliminates Waterfall control gates and review checkpoints that managers and regulators have come to rely on.

It can also mean a lack of auditable decision points and artifacts that can be traced later by auditors and compliance officers. Instead they need to go to the code to find the history of design decisions.

Equally, security is very hard to add later to a system design, and Agile techniques do not naturally encourage security thinking by default (if they did, this book would be unnecessary!).

Agile methods are optimized for the capability to change as the environmental context changes; so as the security landscape emerges and threats change, the team is able to respond quickly, fixing design issues and adjusting the behavior of the system.

Furthermore, Agile practitioners maintain that while they don’t produce as much documentation, their experience of projects is that the documentation rarely matches the reality of the system, meaning that the configuration drift between what is understood in the documentation, and the way the system actually behaves, can be enormous.

By pushing security, auditors, and compliance teams to look at the actual code, they encourage an understanding of the reality of the system rather than the imagined reality of a design document.

Self-Organized, Autonomous Teams

Agile teams tend to work in a highly self-organized and autonomous manner. They have control over their workload, the product backlog, and the manner of delivery.

This means that unlike in some more traditional software engineering shops, Agile teams may resist or avoid review boards, design authorities, and other control mechanisms imposed from outside if they believe that these outside forces will get in the way of delivery. This is a problem for security professionals who are used to working with architecture review boards and other central authorities to set guiding principles and rules to ensure the security of all systems.

Furthermore, this tends to mean that management has less insight into, and control over, each team’s detailed development processes and the bill of materials for the software: the libraries and frameworks used in development. This can raise concerns for audit and compliance teams that want to know exactly how work was done and which software products are using which versions of libraries.

Agile teams ask management to rely on the team to do the right thing, and on the individual capability and competence of the Product Owner to ensure that quality is built in.

Agile advocates argue that top-down control and decision making in traditional engineering methodologies often result in decisions that are inefficient for the individual team or product, and that changing those decisions becomes harder and slower due to the larger blast radius of a decision.

For example, an individual product team deciding to upgrade a library to the latest version affects only that team, but getting an architecture review board to approve the change might require understanding the impact on every team in the organization.

Self-organized and autonomous teams reduce the risk of slow decision making and create firewalls between distinct teams, meaning that vulnerabilities affecting a single team may not necessarily affect all the teams in the organization. It also gives the organization the ability to respond in a more targeted and appropriate way within each team.

Automation

Agile teams rely on automation heavily in order to get the speed, repeatability, and consistency that they need to keep moving forward.

However automation itself comes with its own risks. The tools themselves can be the target of attack and an attack vector in themselves, something we will look at in Chapter 13, Operations and OpSec.

Automated systems can allow mistakes, errors, and attacks to be propagated and multiplied in far more damaging ways than manual systems. As the DevOps comedy account @DevOpsBorat says, “To make error is human. To propagate error to all server in automatic way is #devops.” ²

Furthermore, automated tooling is fallible; and as we know so well in the security world, it can be easy for humans to begin to trust in the computer and stop applying sense or judgment to the results. This can lead to teams trusting that if the tests pass, the system is working as expected, even if other evidence might indicate otherwise.

Automated configuration management and build and deployment pipelines can help enforce separation of duties by providing authenticated and audited systematic access for making system changes, minimizing or eliminating the need for developers to log on directly to production systems. But automation can also interfere with separation of duties, making it hard to define who actually has access to a system and who has the ability to change the system. We’ll explore this issue in detail in Chapter 14, Compliance.

Agile Risk Mitigation

Agile methods also provide some risk mitigations to existing practices.

Waterfall, V-model, and other traditional software engineering systems are known to be subject to cost, scope, and schedule overruns. Agile projects are just as subject to overruns, but managers of Agile projects tend to have greater awareness of overruns earlier, and the principles of YAGNI (you aren’t gonna need it), just-in-time prioritization, and continuous delivery of working software with iterative improvement means that it’s easier to cancel a project and still deliver value to the organization.

Furthermore, frequent demos, shorter feedback loops, designing around a Minimum Viable Product, and the ability to respond to change means that the business risks of delivering software that doesn’t actually meet the user needs are significantly reduced.

Evidence has shown repeatedly over the decades that changes to the system later in the development cycle are more expensive than changes early on. However, the traditional response to this has been to lengthen and ossify the earlier stages in development, attempting to build more complete and comprehensive requirements and designs, rather than focusing on minimizing the cost of change.

Even if a project is delivered well in a Waterfall or V-model system (as many are), systems are only being built for a very short period of their active life and spend most of their life being in service and requiring maintenance and change. Agile methods can help to reduce the costs and the risk to the business of implementing these whole life cycle changes.

Finally, a symptom of this problem is that many systems build in large amounts of configurability and design complexity to anticipate or minimize the cost of future changes. Some common examples are the use of “Business Rules Engines” and “Enterprise Service Bus” platforms to externalize the more frequently changed components of the system and make them easier to change.

However, these approaches add further complexity and operational management overhead to the systems that the organization needs to run. They also add huge complexity to testing and replication of the environments, as changes need to be tested in the presence of many possible configurations.

Software developed following incremental Agile and Lean approaches should be simpler by design; and if the organization is capable of writing and releasing code to change the system at speed, then it can be significantly simpler. Simple systems contain far fewer moving parts and significantly less risk. They are easier to understand and reason about, and this gives us better security properties.

Finally, the more often that you make changes, the more chances that you have to break things. Agile, and especially DevOps teams, make changes much more frequently. Counterintuitively, research shows that organizations that change the most often actually have lower failure rates and higher reliability.³

How do they do this?

Releasing changes in smaller batches, and using dark launching and progressive canary releases to manage the risk of deploying changes.
Optimizing for MTTR (mean time to recovery) by anticipating failure and preparing to deal with it.
Automating configuration management and deployment to ensure consistency and repeatability.
Building feedback loops into production operations and from production into development to catch problems quickly so that they can be fixed quickly, and building an effective incident response capability.

Agile and DevOps teams don’t have to think too much about how to deal with these kinds of risks, as long as they follow the patterns and use their tools properly. Their success depends a lot on the Product Owner understanding the importance of minimizing technical and operational risks and agreeing to prioritize the work necessary, and on the Scrum Master and the rest of the team to work responsibly, and on trust and open collaboration at all levels to eliminate misunderstandings and to bring problems to the surface so that they can be solved.

For larger projects, enterprise Agile program management frameworks like SAFe (the Scaled Agile Framework) and DAD (Disciplined Agile Development) take risk management beyond the team level. They add explicit up front planning and design, reporting and integration checkpoints between teams, and additional roles for architecture and program management to manage risks and dependencies between teams and programs.

Many experienced Agile practitioners and experts are skeptical of these promises, since it has proven to be incredibly difficult to reconcile traditional Waterfall and project management approaches with the principles of Agile. These enterprise management frameworks may help your organization transition to Agile without throwing away all the management best practice that it has built up over time, but we recommend that you tread carefully and ensure you don’t miss out on the full benefits of Agile in following them.

Handling Security Risks in Agile and DevOps

Security professionals often separate themselves from risk management professionals. They like to argue that business risks are significantly different from security risks, that security is a special approach in software development.

This is true to a certain extent. Security risks tend to be far less well understood than traditional business risks, far more easily described as “unknown unknowns,” and far harder to measure in terms of loss or impact.

However, security is another quality of software, in the same way that performance, quality, efficiency, and usability are qualities of the software.

Agile development techniques have sometimes struggled with these qualities, usually referred to as nonfunctional requirements, because it is very difficult to write these into user stories in the same way that user features can be described.

These qualities, including and especially security, have to become something that the team is aware of, owns, and manages internally throughout every story that is delivered.

Security risks can be managed the same way as other risks, by building risk management into how you design, develop, test, and deploy software, and how you run the system.

In a traditional software development life cycle, risk assessment is done based on the system requirements and design specifications and models created up front. A risk analyst uses those documents to identify the risks that will reside in the system and puts together a plan to monitor and mitigate these risks. Then audits are done to ensure that the system built matches the documented design specifications and that the risk management plan is still valid.

In iterative, incremental, Agile development environments, risk needs to be continuously reassessed and continuously managed.

There are several opportunities in Agile methods, such as Scrum, where security and compliance risk management activities can be wired in:

Sprint planning: Review and record risks.
Story writing: Watch out for stories that add security and privacy risks, and counter security and compliance risks by writing security stories, attacker stories, and compliance stories.
Test writing: Add automated security tests and compliance checks.
Coding: Use vetted libraries and patterns.
Code reviews: Ensure that code (especially high-risk code) is reviewed for security risks and ensuring that all code is scanned using automated static analysis tools.
Refactoring: Reduce technical complexity in code and design through disciplined refactoring.
Design: Conduct threat modeling when high-risk changes are made to the system’s attack surface.
Retrospectives: When the team meets to look at improvement opportunities, consider security risks, compliance risks, and other technical and operational risks, and how to manage them.
Postmortem reviews: Use feedback from a failure or incident to examine underlying risks and to come up with solutions.

Risk management also builds on and drives automation and standardization in testing and deployment through continuous integration and continuous delivery. And risk management informs configuration management, monitoring, and other operations practices.

Essentially, all the practices, tools, and methods described in this book are part of your risk management program.

Key Takeaways

Most developers, especially in Agile environments, don’t explicitly deal with risk management, because they don’t have to. Agile techniques and practices help developers take care of many basic project risks, technical risks, and business risks.

Managing security risks, privacy risks, and compliance risks has to be integrated into how developers think and work in the same way as other risks:

Help the team to understand common security risks, such as the OWASP Top 10, and how they are commonly managed.
Make security risks and other risks visible to the team (and to management) in a risk register, or as security stories or compliance stories in the backlog.
Risks and risk management should be explicitly considered in the team’s retrospectives and continuous improvement feedback loops.
By continuously making small, frequent changes, Agile teams reduce operational and security risks. Small changes are easier to understand and test, safer to roll out, and easier to fix if something goes wrong.
Risk management in Agile needs to be done on an interactive basis. Decisions to accept or otherwise mitigate risks need to be re-evaluated over time as the design of the system changes.
Take advantage of Agile and DevOps practices and built-in control points to add risk management controls and provide evidence for auditors. We look at this in more detail in Chapter 14, Compliance.