Home
Services
Security Requirements

02Station 02 · Design

Security Requirements

Security written as requirements your developers can build and test: rate limits, audit trails, data rules and abuse cases, in the ticket from day one.

Book a call →Walk the line

From story to criteria

Pick a step, or let it play. Every line is what someone in the room actually says.

Step 1Start from the story

The user story and the business goal, as product wrote them.

PRODUCTAs a user, I see partner offers and redeem one with my points.

ATALAIAGood. Now, what should never happen with this story?

Leaves the roomStory: redeem a partner offer

Step 2Ask the non-functional questions

Data, identity, limits, logging, failure and abuse.

ATALAIAHow many redeems a minute is normal for one user?

PRODUCTTwo, maybe three. Ten would be a bot.

DEV LEADWe log the voucher code today. Should we?

ATALAIALog that it happened, never the code. A code is money.

Leaves the room6 questions, 6 answers

Step 3Write them as criteria

Testable acceptance criteria, not guidelines.

DEV LEADCriterion: at most 5 redeems a minute per user, then a 429.

QATestable. And an abuse case: a bot redeeming from 50 accounts.

DEVELOPERAn audit event for every redeem, without the voucher code.

Leaves the room6 criteria in the ticket

Step 4Make it a baseline

The common ones become the default for every new service.

ATALAIARate limits, audit events and secret rules go into the service baseline.

DEV LEADSo the next service starts with them, and nobody argues them again.

Leaves the roomBaseline: 12 rules for every service

ATALAIA
PRODUCT
DEV LEAD
QA
DEVELOPER

One story, before and after

The same ticket. On the left, as product wrote it. On the right, after one conversation.

User story · REW-214

As a user, I can redeem a partner offer with my points.

Acceptance criteria

Offer shows a voucher code
Points balance goes down

User story · REW-214 · after the conversation

As a user, I can redeem a partner offer with my points.

Acceptance criteria

Offer shows a voucher code
Points balance goes down

LIMITSAt most 5 redeems per user per minute, then 429.
IDENTITYOnly the owner of the points can redeem, checked on the server.
DATAVoucher codes are never logged and are masked in support tools.
AUDITEvery redeem writes an event: who, what, when, result.
FAILUREIf the partner times out, the points come back within a minute.
ABUSERedeems from many new accounts are flagged. QA owns the test.

Why it matters

“Log that it happened, never the code. A code is money.”
ATALAIA · step 2, Ask the non-functional questions

If security is not in the requirement, it arrives as a finding. Developers then fix it under deadline, in code that was never designed for it.

What you get

A requirement set per feature, in the format your team already uses
Abuse cases written next to user stories
A reusable baseline for every new service
Test ideas QA can automate

Typical shape: Alongside planning, a few hours per feature, then a baseline you keep.

Next on the line

Every station reports to the same tower. These are the neighbours.

Station 03 · DesignThreat Modeling

Business, devs and cyber, one table

See the station →Station 11 · Release & testQA Security Testing

Checks your QA team can own

See the station →Station 17 · ProgramAppSec Program Build

From a team of one to a working program

See the station →

Talk it through

A 30-minute call. No slides, no price list, and a next step either way.

Book a call →Walk every station