Security in custom software: the checklist we build against
The twenty controls we apply to every application, grouped by what they protect, so you can ask about each.
The short answer
Security in custom software is not a test at the end; it is a set of controls designed in from the start and verified continuously. We build every application against the same twenty, grouped by what they protect: identity and access, input and output, data, dependencies and secrets, infrastructure and headers, and monitoring and response. Real breaches of business applications come from a handful of them: access control not enforced on the server, injection through unvalidated input, vulnerable dependencies, secrets exposed in code or the front end, and no logging to notice any of it. The list is here so you can ask about each item by name.
The checklist
| Group | Control | Verified by |
|---|---|---|
| Identity and access | 1. Authentication through an established provider or library | Review |
| 2. Two-factor for staff and administrators | Configuration | |
| 3. Permissions checked on the server for every request, by permission not role name | Tests that try to cross boundaries | |
| 4. Secure sessions: cookie flags, expiry, invalidation on logout and password change | Review, scan | |
| 5. Rate limits on login, reset and sensitive endpoints | Configuration, test | |
| Input and output | 6. All input validated on the server against a schema | Review, tests |
| 7. Parameterised queries everywhere; no string-built SQL | Review, static analysis | |
| 8. Output encoded for its context; content security policy set | Scan, review | |
| 9. File uploads validated by content, stored outside execution, served through signed links | Review, tests | |
| Data | 10. Encryption in transit everywhere and at rest for stored data and backups | Configuration |
| 11. Data minimisation: collect and retain only what is needed, with retention automated | Design review | |
| 12. Personal data mapped: where it enters, rests, flows; processor agreements in place | Documentation | |
| Dependencies and secrets | 13. Lock file, automated advisories, updates within days for security fixes | Pipeline |
| 14. Secrets only in platform configuration; never in code, front end or logs | Secret scanning in pipeline | |
| 15. Least-privilege keys for every service, rotated on a schedule and on departure | Review | |
| Infrastructure and headers | 16. Security headers: HSTS, CSP, frame, content-type, referrer | Scan on every deploy |
| 17. Separate environments with separate credentials; no production data in staging | Configuration | |
| 18. A network layer in front filtering attacks and bots | Configuration | |
| Monitoring and response | 19. Logging of security events and audit trail of sensitive actions; alerts to a person | Test alert |
| 20. An incident plan, tested; a way to pause features and revoke access quickly | Tabletop exercise |
The five that prevent the breaches that happen
- Server-side permission checks on every request. The most common failure in custom applications and the most damaging: one missing check exposes every record.
- Validation and parameterised queries. Injection remains a leading cause of data theft, and it is entirely preventable.
- Dependency updates. Known vulnerabilities in old packages are scanned for by attackers within hours of publication.
- Secrets out of code and front end. An exposed key is found by scanners in minutes.
- Logging with alerts. Without it, the other failures are discovered by customers, months late.
Using the list
Ask your builder to walk through it for your application, item by item, naming the verification for each. Ask which items the pipeline checks on every change. Ask when the last penetration test or scan was and what it found. For regulated sectors, ask what is layered on top. The conversation takes an hour and tells you more about the security of your software than any certificate on a website.
What this means for you
Security in your software is twenty controls, designed in and verified continuously, of which five are where the real breaches start. Use the list to ask specific questions and expect specific answers with a verification mechanism for each. A builder who can walk through it without hesitation has built this way before. One who cannot is offering intentions, and intentions are not a control.
Frequently asked questions
Is this list enough for a regulated business?
It is the baseline every application needs. Regulated sectors add requirements on top: specific encryption standards, audit retention, access certification, penetration testing cadence, documentation for auditors. The baseline makes those additions possible; without it, the sector requirements are built on sand.
How do we verify the controls are actually in place?
Some are checked by the pipeline on every change: dependency advisories, secret scanning, header checks, tests that try to cross permission boundaries. Some are checked in code review. Some are verified by a periodic scan or penetration test. Ask which mechanism verifies each item; a control with no verification is an intention.
Which items matter most?
Access control enforced on the server for every request, because it is the most common and most damaging failure. Then input validation and parameterised queries against injection, dependency updates, secrets out of the code and the front end, and logging with alerts so that an incident is noticed. Those five are where real breaches in business applications start.
Sources
- OWASP Top 10 (accessed 2026-09-12)
- OWASP Application Security Verification Standard (accessed 2026-09-12)