What the requirements looked like
In regulated industries such as insurance and pensions, the security requirements I have seen come as a short, firm list. Short does not mean small. Each item changes how the system is built and where it runs:
- A private VNet. The application and its data sit in a private network, reachable only through controlled entry points.
- Audit. The ability to show who did what, and when.
- Logs for all application events, not only for errors.
- Redundant data, so that one failure does not lose it.
- A disaster recovery policy, written down and agreed, not only implemented.
Why they belong in the plan on day one
These requirements are expensive to add late. A private network affects every environment and every integration. Logging for all events touches the design of every feature, and redundancy and recovery affect how the platform is run. Adding them near the end is closer to a rebuild than to a task.
Security added at the end is a rebuild, not a task.
On a fixed price there is a second reason. A requirement that nobody priced is a hidden discount, and it surfaces when the team is already stretched. This links back to the offer: security expectations belong next to the price, written as assumptions, before signature.
Redundancy and disaster recovery are where cost and ambition meet, because the more failure the client wants to tolerate, the more the platform costs to run. I try to have that conversation in plain terms early: what must be recovered, how quickly, and what the client is prepared to pay for it. A recovery policy nobody has ever tried is a document, not a protection, so I ask for it to be rehearsed before go-live.
How I handle them
I ask for the security requirements during discovery, and I ask who on the client side owns them, because the answer usually sits with a security or compliance function and not with the business sponsor. I write them into the scope baseline like any other requirement, with an owner and a way to prove them.
Proof matters as much as the control. An audit trail or a recovery policy that cannot be shown to the client's reviewers is worth little on the day they ask. I plan the evidence together with the work, and I treat these items as part of acceptance, not as a document written in the last week.
Logs deserve a note of their own. Logging every event creates a lot of data, and logs can hold personal information. Who may read them, where they are stored and how long they are kept are questions to settle with the client, not defaults to accept.
Compliance and data protection
I am not a lawyer and I do not pretend to be one. For compliance and data protection I ask the client's own specialists early, about where the data may live, who may see it and how long it is kept, and I put their answers in writing. An answer in an email in week two is cheap. The same answer discovered in month six is not.