In 2019, during my MSc in Agile Leadership, I ran an action research project dramatically titled “The Life and Times of Miscreants, Attackers, Abusers, Misusers and Evil Folk.” I looked at how agile teams can use negative user stories to spot and manage information security risks. In academic writing, these are often called “abuser stories” (a term Johan Peeters coined in 2005) or “evil user stories” (later popularised by OWASP). I now call them Security Stories, because they describe malicious viewpoints we must design against and not real users we are building for.
What Are Security Stories in Agile and ITSM?
Writing Security Stories Using the “As a… I want… so that…” Format
We write them just like we do with a user story in the popular [As a…I want…so that] format.
| As a malicious Student, I want to modify my account balance so that I can get Cookies and Chicken Wraps without paying. |
Figure 1 – Sample Security Story
Why Security Stories Matter for Modern Digital Services
Security Stories are negative “what if” scenarios written from an attacker’s viewpoint, describing how someone might try to exploit a system and what the system must do to prevent it. By adding these stories to the requirements backlog, teams can proactively address security issues as part of normal development, rather than reacting to them after a breach or during a late security audit.
Now, with ITIL (Version 5) in play, I am struck by how well Security Stories align with its emphasis on designing for quality, managing risk, assuring warranty, and strengthening the Information Security Management practice. The design stage of ITIL’s Product and Service Lifecycle is where these techniques have the biggest impact, and that is where this post will focus.
Aligning Security Stories with ITIL (Version 5) Principles
ITIL (Version 5) provides a framework for delivering value through products and services, with several of its concepts resonating as far as the use of Security Stories:
Embedding Risk Management into Agile Development
In ITIL, a risk is a potential event that could cause harm or impede objectives. Each Security Story documents a risk scenario: a possible attack and how to counter it. Using Security Stories means you are doing continuous risk management within each development sprint. This aligns with ITIL’s Risk Management practice, defined as ensuring that an organization understands and effectively handles risks, by giving teams a concrete way to capture and mitigate threats as part of day-to-day work.
Enhancing Service Quality Through Built-in Security
Quality is the ability of a service to meet both stated and implied needs. Security is often an implied need. Users might not request it formally, but they certainly expect their data and services to be safe. Security Stories turn those implicit requirements into explicit plans. By including security-focused acceptance criteria in your definition of done, you make sure the delivered service meets customer expectations for safety and reliability, thereby boosting overall quality.
Strengthening Warranty: Reliability, Continuity, and Protection
Warranty in ITIL is about a service being fit for use, covering reliable performance, capacity, continuity, and security. A service might have brilliant features, but if it is unstable or insecure, it lacks warranty and will frustrate users. Implementing Security Stories improves warranty by building robust security and resilience into the service design. In essence, each Security Story is a commitment that the service will protect data and remain dependable even under adverse conditions.
Embedding Security in the Service Design Stage
The design stage is a critical phase for incorporating security requirements. This is when ideas turn into detailed specifications for how a service will work and be supported. It is far easier and cheaper to build security into a design than to retrofit it later. In ITIL (Version 5), design goes beyond technical architecture; it also incorporates experience, usability, supportability, and sustainability, with the aim of anticipating operational and technical challenges before they reach production.
In my own research, I ran cross-functional workshops with colleagues from IT Systems, IT Infrastructure, the Service Desk, and representatives from other areas of the College. We used techniques like attacker personas, misuse case diagrams, and rich pictures to surface potential threats in a proposed system. Each significant threat was turned into a Security Story and added to our backlog in Jira, right alongside the regular user stories. If we identified a risk, such as an attacker injecting malicious code via a web form, the corresponding Security Story prompted developers to implement input validation and sanitization in that form’s design. By treating these as first-class design requirements, we ensured that critical security controls were not left to chance during development.
Before the project, no methodical information security risk assessment had been carried out in the team. That changed. The artifacts we created were managed in our day-to-day tools (Jira, Confluence), fitting into the team’s existing agile workflows. The result was that many potential vulnerabilities were addressed on paper before any code was written. This prevented last-minute surprises and meant that security features like encryption, audit logging, and role-based access controls were designed in from the start and could be verified during testing as part of normal quality assurance.
How Security Stories Support Design and Information Security Management
To illustrate, here is how Security Stories contribute to both Design and the Information Security Management practice in ITIL:
| Area | In ITIL | With Security Stories |
| Design | Plans new/changed services to be fit for purpose and fit for use. Covers requirements plus key non-functional needs (support, performance, continuity, security). | Turns likely attack paths into design requirements and controls (e.g., validate/sanitize inputs) so security is built in early – reducing rework later. |
| Information Security Management (Practice) | Protects confidentiality, integrity, and availability by translating policy and risk appetite into controls. | Makes policy actionable by converting goals (e.g., protect data, prevent unauthorized access) into backlog items for delivery teams – embedding security in day-to-day work. |
This process instills a mindset that security is not an afterthought. As someone once put it to me: “Security isn’t something you can add on at the end; it needs to be woven into the fabric of everything you do in building services from the outset.” By adopting Security Stories in the design phase, you align with ITIL’s emphasis on integrating quality, risk, and security considerations throughout the lifecycle, rather than treating them as final checklist items.
Real-World Lessons from Implementing Security Stories
In my project, I observed a few key changes:
Moving from Reactive to Proactive Security
We stopped treating security as a box-ticking exercise at the end of development and started addressing it during planning and design. This cultural shift, supported by the iterative Plan, Act, Observe, Reflect cycle of action research, led to far fewer surprises and a smoother path to production.
Improving Cross-Functional Collaboration
Security Stories gave us a shared language between development and our security and compliance colleagues. With threats and mitigations documented in our backlog, we could easily show how each risk was being addressed. This transparency built trust and made audits and approvals much smoother.
Delivering Secure, Resilient Services by Design
Each Security Story came with clear acceptance criteria (for example, “all confidential data must be encrypted at rest and in transit”), which guided our testing. We caught potential vulnerabilities early, when they were easier and cheaper to fix. As a result, we delivered a service that was not only feature-rich but also secure, stable, and resilient by design from day one.
Conclusion: Building Secure Services from the Start
Security Stories give IT service management (ITSM) practitioners and developers a practical way to integrate security into their services right from the start. By constantly asking “How might someone maliciously exploit this?” and building the answers into your requirements, you ensure each new or changed service comes with its necessary safeguards. This approach supports ITIL’s goals by uniting risk management, quality assurance, and information security with agile development. Ultimately, it leads to digital services that meet their functional objectives and maintain the trust of users and stakeholders through strong security and reliability.
Further Reading
- Johan Peeters, “Agile Security Requirements Engineering” (2005). Introduction to the concept of negative user stories in agile development.
- OWASP, “Abuse Case and Evil User Stories”. Practical guidance on writing negative user stories for security.
- Stephen Mann, “ITIL (Version 5) Management Practices Explained” (ITSM.tools, 2026). Overview of all 34 ITIL v5 practices, including the role of Information Security Management in the new framework.
- Alex Harding, “The Life and Times of Miscreants, Attackers, Abusers, Misusers and Evil Folk” (UCLAN 2019). My MSc Project.
- PeopleCert, “ITIL (Version 5)” (2026), Foundation, Product, Service, Experience, Strategy & Transition
Security Stories FAQ
A Security Story is a negative “what if” scenario written from an attacker’s viewpoint. It describes how someone might try to exploit a system and what the system has to do to stop them. Adding these to the requirements backlog lets teams deal with security issues as part of normal development rather than after a breach or during a late audit.
They describe the same idea. “Abuser stories” is the term Johan Peeters coined in 2005, and “evil user stories” was later popularized by OWASP. Alex uses “Security Stories” because the term focuses on the malicious viewpoints you design against, not real users you’re building for.
They map onto several ITIL v5 concepts at once. Each story documents a risk scenario, which supports the Risk Management practice. Security-focused acceptance criteria feed into quality and warranty. And the technique does most of its work in the design stage of the Product and Service Lifecycle, where building security in is cheaper than retrofitting it later.
You use the same “As a… I want… so that…” format as a standard user story, but from the attacker’s perspective. Alex’s example: “As a malicious student, I want to modify my account balance so that I can get cookies and chicken wraps without paying.”
No. In Alex’s project they sat alongside regular user stories in Jira and worked through cross-functional workshops using attacker personas, misuse case diagrams, and rich pictures. They’re a way to surface and document threats inside an existing agile workflow, not a substitute for testing, controls, or assessment.
Alex Harding
Alex is an award-winning IT and digital services leader, an SDI Distinguished Industry Contributor with 20+ years’ experience across service management, cyber security, and organizational change. A Chartered IT Professional, ITIL Master, and ITIL Ambassador, he has led teams delivering high-performing service desks, major transformation programs, and sector-leading information security, with a focus on inclusive, people-centered leadership in FE.
