Security Is Not a Phase

The penetration test is booked for the last week before launch. Everyone knows the date. It sits in the plan as a box called “Security”.

That box is the problem. A test in the last week can only find what is already there. By then the way data travels, the platform the product stands on, the path a change takes to production, and who is allowed to do what have all been decided. The test reports symptoms. The causes are months old.

Security is not a phase. It is a property of ordinary decisions, and most of them are made early, by people who did not think they were making a security decision at all.

What a phase costs

When security is a phase, findings arrive at the worst possible moment: everything is built, the launch date is fixed, and the fixes are structural.

The expensive ones are always the same kind. An identity model that has to be redone with real users already in it. A database reachable from places it should never have been. A dependency nobody chose deliberately that now carries a critical advisory. None of these are found by a scanner in week one. All of them are cheap in week one and ruinous in the last week.

Four places security is decided before anyone tests it

How data travels and where it rests. For a water-treatment company we built ReportSync, which moves inspection reports from field devices into the company CRM. The transport was a secure tunnel from the first version, and every failed upload is logged, retried and shown to a person. That last part is security too. A system that loses data quietly cannot be trusted, whatever its encryption.

What the product stands on. A medical device company came to us for an online catalogue of more than 10,000 products. The obvious answer was a plugin-based shop platform. We recommended against it, partly for performance, partly because at that size plugin sprawl is attack surface. Every plugin is code someone else maintains, on their schedule, inside your application. Choosing the platform was the security decision. It just did not look like one.

How a change reaches production. The Subcontractor Portal for a construction company runs on private German cloud infrastructure, and every change walks the same path: development, QA, test, live, each its own environment. Nobody edits a live server by hand, because there is no way to. That is not a security feature in the product. It is the shape of the delivery, and it removes an entire class of incident.

Who may do what, and how you know afterwards. A manufacturer with 5,800 employees needed visitor compliance onboarding across several sites: briefings, signatures, recorded approvals before anyone enters a facility. The client’s word was “auditability”. Roles, approvals and the record of who did what are domain design. If they are modelled properly, the audit trail exists because the system works, not because someone added logging later.

What this looks like inside a sprint

None of it is heroic. A ten-minute threat sketch when a feature is designed: what is the data, who touches it, what would an attacker want. Dependency scanning in the pipeline, so an advisory is a failed build, not a surprise. Secure defaults: deny unless allowed, least privilege for every service account. Secrets that never enter a repository. Logs that can answer “who did what, when” without a forensic project.

Each of these is a small habit. Together they mean the last-week test confirms rather than discovers.

The test still happens

We still book the penetration test. The difference is what it is for. In a delivery where security is a phase, the test is where you find out. In a delivery where security is a property, the test is where you prove it. Same test, opposite meaning.

If you have a launch coming and a “Security” box in the plan, it is worth a conversation before that box arrives. See how we run delivery and infrastructure, or talk to us.