Building a Security Culture in a 20-Person Startup

Security culture is not something you buy. It is something you build. And in a 20-person startup where everyone wears multiple hats and moves fast, building security culture requires a different approach than what works at a Fortune 500 company.

You cannot mandate security culture through policies and training videos. You have to make it part of how people work every day.

Start with the founders

Culture flows from the top. If the founders treat security as a nuisance that slows down shipping, the team will too. If the founders visibly prioritize security, use strong passwords, enable MFA on everything, and talk about security risks in all-hands meetings, the team follows.

This does not mean the founders need to become security experts. It means they need to signal that security matters. When someone reports a security concern, thank them publicly. When a security improvement ships, celebrate it the same way you celebrate a new feature. When a security incident happens, lead the post-incident review without blame.

Make security easy

The biggest enemy of security culture is friction. If the secure way to do something is significantly harder than the insecure way, people will take shortcuts. Your job is to make the secure path the path of least resistance.

SSO everywhere. When signing into every tool requires a separate username and password, people reuse passwords. When everything goes through SSO, they use one strong password and MFA. Set up Google Workspace or Okta and connect every SaaS tool you use.

Password manager. Provide a team password manager (1Password, Bitwarden) and make it the standard way to share credentials. This eliminates passwords in Slack messages, sticky notes, and shared documents.

Automated security tooling. Install pre-commit hooks that catch secrets before they reach git. Run dependency scanning in CI so vulnerabilities are caught automatically. Use infrastructure-as-code so security configurations are version-controlled and reviewed in pull requests.

Train through doing, not slideshows

Annual security awareness training with a 45-minute slideshow does not change behavior. Instead, integrate security into the work itself.

Code review checklists. Add security items to your code review checklist: input validation, authentication checks, SQL parameterization, error handling that does not leak information. Every developer reviews every pull request with these items in mind.

Phishing simulations. Run a quarterly phishing simulation using a tool like KnowBe4 or GoPhish. When someone clicks, do not punish them. Use it as a teachable moment. Share results with the team (anonymized) and discuss what made the phishing email convincing.

Lunch-and-learn sessions. Once a month, have someone present a 20-minute talk on a security topic relevant to your business. Rotate presenters so everyone learns by teaching. Topics: how HTTPS works, common API vulnerabilities, what happens during a breach, how to read a security advisory.

Create security champions

In a 20-person startup, you probably do not have a dedicated security team. Instead, identify 2 to 3 people across different functions (engineering, product, operations) who are interested in security. Give them the "security champion" title, send them to a security conference or training course, and make them the go-to people for security questions within their teams.

Security champions are not responsible for doing all the security work. They are responsible for keeping security top-of-mind within their functional area. They review pull requests with a security lens, flag potential risks in product discussions, and escalate concerns to leadership when needed.

Make reporting safe

People need to feel safe reporting security concerns. If someone discovers they accidentally committed a credential to git, they should feel comfortable reporting it immediately, not hiding it and hoping nobody notices.

Create a #security channel in Slack where anyone can report a concern. Respond to every report with gratitude, regardless of severity. Never punish someone for making a mistake. Punish people for hiding mistakes.

The same applies to external security researchers. Set up a security.txt file and a responsible disclosure page. If someone finds a vulnerability in your product, make it easy for them to report it and respond promptly.

Measure and iterate

Track security metrics monthly: number of reported concerns, time to patch critical vulnerabilities, phishing simulation click rates, percentage of tools behind SSO, and MFA adoption rate. Share these metrics with the team and set improvement targets.

Security culture is not a project with a completion date. It is an ongoing practice that evolves as your company grows. The 20-person startup that builds strong security habits early will scale those habits to 200 people. The one that waits until 200 people to start will find it 10x harder.

If you need help building a security program and culture for your startup, reach out. This is the core of what a fractional CISO does, and we can help you find the right balance between security and speed.

Joiners and leavers are the backbone

Every cultural habit described above degrades if onboarding and offboarding are improvised. At 20 people you can get away with a founder adding accounts by hand, and that is exactly how you end up with a former contractor holding a GitHub seat eight months after the contract ended. The fix is boring and takes an afternoon.

Write two checklists and store them where the person doing the work will actually find them, which is usually the same place your engineering runbooks live. The joiner list names every system a role gets, the group or role that grants it, and the person who approves anything outside the default. The leaver list names the same systems in the order that matters, starting with the identity provider session revocation and the password manager, because killing SSO first closes most doors at once. Add the systems that sit outside SSO to the leaver list explicitly, since those are the accounts that survive: the AWS root account, the domain registrar, the payment processor, a database console with local users, and whatever CI tool holds long-lived deploy tokens.

Then close the loop. Once a quarter, pull the user list from your identity provider and compare it against your HR list of current staff. Anything on one and not the other is either a leaver you missed or a shared account somebody created outside the process. This takes about half an hour once the exports exist, and it is the single highest-value recurring habit a company of your size can adopt. It also happens to produce the access review record that SOC 2, ISO 27001 and most enterprise questionnaires ask for, so the work counts twice.

Turning culture into evidence a buyer accepts

The moment a prospect sends a security questionnaire, culture becomes a documentation problem. Buyers do not accept "we have a strong security culture" as an answer. They ask whether all staff complete security awareness training at hire and annually, whether there is a signed acceptable use policy on file, whether background checks are performed where permitted, and whether there is a documented process for revoking access on termination.

Those are all things you are probably doing informally. The gap is the record. A lunch-and-learn with no attendance list evidences nothing. A phishing simulation with results nobody saved evidences nothing. Get in the habit of producing a dated artifact for each: an attendance record with names, an export from the phishing tool showing the campaign date and click rate, a signed or acknowledged policy per person with a timestamp. Store them somewhere the whole team can reach rather than in one founder's Drive folder. Our free Workspace holds this kind of register with owners and refresh dates attached, and you can use it without buying anything from us.

Doing this from the start costs almost nothing. Reconstructing a year of training records the week before an audit costs a fortnight of somebody's life and still produces thin evidence.

The failure modes we see most

Champions with no time. Naming two security champions and then loading them at 100 percent on roadmap work produces a title and no behavior change. If the role is real, it needs protected hours on the calendar and an outcome the person is measured on, even something as small as owning the dependency upgrade queue.

The phishing simulation that damages trust. A simulation impersonating a payroll change or a bonus announcement will get high click rates and a demoralized team. Test realistic attacks against your business, such as a fake vendor invoice or a spoofed Google Workspace login, and never attach consequences to a click. Companies that run punitive simulations get lower click rates and near-zero real reports, which is the opposite of the outcome you want.

Metrics theater. Tracking MFA adoption is useful when it moves someone to close the gap. Tracking it in a slide nobody acts on is overhead. Pick two numbers you will actually act on. Percentage of accounts behind SSO and median days to patch a critical vulnerability are usually the pair that drive the most behavior.

The silent Slack channel. A #security channel where reports go unanswered for two days teaches people not to report. If nobody can commit to same-day acknowledgement, route reports to a named person by direct message instead and be honest about it.

Policies written by a generator. Downloaded policy packs describe a company you are not. When an auditor samples against a policy saying you perform annual penetration testing and formal vendor risk assessments, and you do neither, the policy has created the finding. Write the shortest honest version and expand it when the practice catches up.

What breaks between 20 and 60 people

The habits that work at 20 depend on everybody knowing everybody. Around 35 to 40 people, the founder stops being able to name every access grant, the first manager layer appears, and a second engineering team starts making its own tooling decisions. That is when informal culture needs structure behind it, and the transition is easier if you built the joiner and leaver checklists early.

What to add at that point, and not before: role-based access groups rather than per-person grants, a written exception process so people stop asking the founder directly, and a vendor review step before a new SaaS tool holding customer data gets a credit card. Adding those at 20 people is premature and will be routed around. Adding them at 60 is late and will be resented.

When you should not spend money on this

At 20 people, with no regulated data and no enterprise customer asking, you probably do not need a fractional CISO yet. The work described in this article is doable by a motivated engineer with a day a fortnight, and paying an outside firm to do it removes the ownership that makes it stick.

You also do not need a paid awareness training platform to start. A quarterly 30-minute session run internally, with the attendance list saved, satisfies most buyers and teaches more than a purchased video course. Buy the platform when headcount makes tracking manual attendance genuinely annoying, which is usually past 50 people.

The point where outside help pays for itself is narrower than most vendors admit: a signed deal blocked on a framework with a date attached, a regulated data type you have never handled before, or an incident that exposed something you cannot diagnose internally. If that is where you are, tell us what the buyer asked for and we will tell you which parts you should keep in-house. If it is not, keep the money and do the checklists.