Secure SDLC for startups: a practical checklist for small teams

What a secure SDLC is

A secure SDLC (secure software development lifecycle) is a way of building software where security work is part of every phase, from the first plan to running the product, instead of one check at the end. For a startup it does not mean a security department. It means a few fixed habits in each phase, written down, so every change goes through them.

Small teams need this for two reasons. Business customers ask security questions before they sign, and a team with clear habits has the answers ready. And a control that is part of the first plan costs little, while the same control added after launch means changing a data model, a process and often a contract.

I spent seven years in information security, running ISMS audits, risk analyses and supplier audits as a consultant and working as an in-house Deputy Information Security Officer. Today I build software, and this is the routine I use. The guide follows six phases: plan, design, build, test, release and run. Each one ends with a short checklist you can copy.

Plan: decide what you protect

Security starts before the first line of code, with a short list of what the product will hold. Write down every kind of data, mark the personal data, and decide for each one why you need it and when it is deleted. Data you never collect cannot leak, and data you delete on a schedule does not pile up.

Then write the security requirements next to the feature requirements. If a feature needs a login, the requirement is not just "users can log in". It is also who can see what after they log in, and what happens after too many failed attempts.

• List every type of data the product stores, and mark the personal data.
• Write down why you need each one and when it is deleted.
• Add security requirements to each feature, in the same place as the feature itself.
• Note the questions your first customers will ask: where data is stored, who can access it, which suppliers receive it.
• Name one person who owns security decisions, even if that is the founder.

Design: draw the data flows

You do not need a security team to model threats. List what you protect, who might want it and how they could get it. Then fix the most likely path first. A simple drawing of where data enters, where it is stored and which outside services receive it does most of the work.

Every outside service in that drawing is a supplier. When I assessed suppliers, four questions did most of the work, and they apply to every hosting provider, AI vendor and payment service you plan to use: Where does the data go? Who can access it? What happens if they are breached? How do we get out again?

Design access rights before you build the login. I was responsible for identity and access management for the banking applications of a direct bank, and the lesson carries over to any product: roles and rights are far easier to define on paper first than to untangle once real users have them.

• Draw the data flow: where data enters, where it is stored, which third parties receive it.
• Answer the four supplier questions for every outside service.
• Define roles and access rights before building logins.
• Plan deletion as a feature, a scheduled job, not a manual task.
• Decide where secrets live, so they never sit in the code or in the browser.

Build: make the safe way the default

In the internal audits I ran, the findings were rarely about clever attacks. They were about basics: access rights nobody reviewed, data kept longer than needed, logs nobody read, configuration left at its defaults. The build phase is where you prevent most of them, by making the safe option the one that happens without extra effort.

Use the protections your framework and database already offer instead of writing your own. Enforce access checks on the server and in the database, never only in the user interface. Keep the list of dependencies short, because every package is code you did not write and still have to trust.

If AI coding agents write part of your code, the same rules apply to them. Put the rules in the project's instruction files so every session starts with them, and never let the agent that wrote a change be the one that reviews it.

• Use the framework's built-in protections for queries, output encoding and forms.
• Check access on the server and in database rules, not only in the interface.
• Set security headers and a Content Security Policy.
• Keep dependencies few, and update them under a written policy.
• Log security events, and keep names, email addresses and message text out of the logs.
• Write the rules down in the project's instruction files, for people and for AI agents.

Test: check the risky paths, not just the happy path

Most tests prove that a feature works for the person allowed to use it. Security tests prove that it fails for everyone else. The most valuable single test in a multi-user product is simple: user A cannot read or change user B's data.

Automate what you can, so the checks run on every change and nobody has to remember them. Then test the things that only show up in the deployed product, such as headers, cookies and endpoints that should not be public.

• Test access control: one user cannot read or change another user's data.
• Test input limits: file types, file sizes, rate limits and malformed requests.
• Scan dependencies and scan for committed secrets on every change.
• Check the deployed configuration: headers, cookies, TLS and public endpoints.
• Test deletion: data is really gone after its retention period.

Release: review before it goes live

Not every change needs the same attention. Changes that touch personal data, accounts or payments get a security and privacy review before they go live. Everything else follows the normal process. This keeps reviews focused on the changes where a mistake would hurt.

Keep development, test and production apart, and keep real customer data out of test systems. Make every release reversible, so a bad change can be rolled back quickly instead of fixed under pressure.

• Review every change that touches personal data, logins or payments before release.
• The reviewer is not the person, or the agent, who wrote the change.
• Separate development, test and production, with no real customer data in test.
• Make every release reversible.
• Record what changed and why, in one place.

Run: keep it secure after launch

Security does not end at launch. Access rights grow, dependencies age and suppliers change their terms. A short, regular routine catches most of this before it turns into an incident or an audit finding.

Give people a way to tell you about problems. A security contact and a security.txt file cost nothing and show that you take reports seriously. Our own approach is on the trust page.

• Review access rights on a fixed schedule, and remove leavers the same day.
• Read the logs, or set alerts for the few events that matter.
• Patch dependencies and the platform on a schedule.
• Check that deletion jobs actually ran.
• Publish a security contact and a security.txt file.
• Know who decides in an incident and how you will reach your customers.

How this lines up with ISO/IEC 27001

Many customer security questionnaires in Europe are based on ISO/IEC 27001. Its 2022 version has a control set for development: a secure development life cycle, application security requirements, secure architecture and engineering principles, secure coding, security testing, separate environments and change management. The six phases above cover the same ground in a form a small team can run.

Aligned is not the same as certified. Certification needs an ISMS and an external audit. XIVU is not ISO 27001 certified and holds no GDPR certification. We build with the GDPR in mind and align our work with ISO 27001, and we say exactly that. If you need to know how far your own company is from the standard, a Security Readiness Review answers that question.

How we use it at XIVU

We built our own product this way. NIUJU, our AI photo studio, deletes uploaded photos automatically 7 days after upload, takes payments through Stripe so we never store card data, and gets a security and privacy review for every change that touches personal data, accounts or payments. The full story is in How we built NIUJU with security by design.

We use the same routine for client work. A Secure Launch project builds a website on this baseline from the first plan, and our security services cover teams that build themselves and want a second pair of eyes. You can read more about my background on the About page.