Building a Security Program from Zero

You just got tapped to “figure out security.” Maybe you’re the first security hire. Maybe you’re a CTO who got a pointed question from an investor. Maybe a customer sent over a security questionnaire and nobody knew where to start.

Whatever brought you here, the starting point is the same: you have no security program, everything feels urgent, and the budget is not infinite.

Here’s how to approach it without losing your mind or wasting six months on the wrong things.

Do Not Start by Buying Tools

This is the single most common mistake. A company decides to “get serious about security,” and the first move is purchasing a vulnerability scanner, a SIEM, an EDR platform, and maybe a compliance automation tool. Six figures later, nobody is using half of it, and the actual risks haven’t changed.

Tools are force multipliers. If you have no force to multiply, they sit on the shelf.

Start with understanding. Then process. Then people. Then tools.

Week 1-2: Know What You Have

Before you can secure anything, you need to know what exists. This sounds obvious, but most companies cannot answer basic questions about their own environment.

Build an asset inventory. Every application, every database, every cloud account, every SaaS tool, every third-party integration. You don’t need a fancy CMDB. A spreadsheet works fine. The goal is a single document that answers: what do we run, where does it run, and who owns it?

Map your data flows. Where does sensitive data enter your system? Where does it get stored? Where does it go? Who can access it? This is the most important exercise you’ll do in the first month. Draw it out. Use a whiteboard, Lucidchart, whatever. The picture will reveal risks you didn’t know existed.

We built a program for an ed-tech company last year and the data flow exercise revealed that student PII was being copied to three different analytics databases, one of which had no access controls. Nobody had done it maliciously. It just happened organically over time. That’s how most security problems start.

Catalog your identities and access. Who has access to what? How are accounts provisioned and deprovisioned? Is there MFA everywhere? How many admin accounts exist? Are there shared credentials?

This isn’t glamorous work. It’s essential.

Week 3-4: Identify Your Top Risks

Now that you know what you have, figure out what could go wrong.

You don’t need a formal risk assessment framework yet. You need a prioritized list of “things that would hurt the most if they happened.” Be concrete.

Not “data breach.” Instead: “An attacker gains access to our production database containing 200,000 student records through a compromised developer laptop with no disk encryption and a reused password.”

That specificity matters because it points directly at what to fix.

For most startups, the top risks cluster around a few themes:

• Credential compromise (weak passwords, no MFA, shared accounts)
• Overly permissive cloud configurations (public S3 buckets, wide-open security groups, root API keys in code)
• No incident detection or response capability (you’d never know if someone was in your environment)
• Third-party risk (that SaaS tool your marketing team signed up for has access to customer data)
• Lack of secure development practices (no code review for security, no dependency scanning, secrets in version control)

Rank them by impact and likelihood. The top 5 are your first projects.

The First 90 Days: What to Actually Do

Here’s a practical sequence. Adjust based on your risk assessment, but this ordering works for most companies.

Days 1-14: Foundations.

• Enable MFA on everything. Every cloud console, every SaaS app, every admin account. Use hardware keys or authenticator apps, not SMS. This is the single highest-impact control you can deploy, and it’s mostly free.
• Implement a password manager company-wide. 1Password or Bitwarden. Kill shared credentials. This takes about a week including rollout and training.
• Enable logging. CloudTrail in AWS, audit logs in your SaaS tools, access logs on your databases. You don’t need to analyze these yet. Just make sure they exist and are being retained. You can’t investigate what you didn’t log.

Days 15-30: Cloud and infrastructure.

• Run a cloud security baseline assessment. AWS has Trusted Advisor and Security Hub. Use them. Fix the critical findings: public resources, overly permissive IAM policies, unencrypted storage.
• Implement least-privilege access. This is painful and takes longer than two weeks to complete fully, but start the process. Review who has admin access and remove it where it’s not justified.
• Set up basic alerting. Console logins from unusual locations, root account usage, security group changes, IAM policy modifications. These are high-signal, low-noise alerts that catch real threats.

Days 31-60: Application and development.

• Enable dependency scanning in your CI pipeline. Dependabot, Snyk, Renovate. Pick one. The point is knowing when your dependencies have known vulnerabilities.
• Implement secret scanning. Tools like truffleHog or GitLeaks catch secrets that have been committed to your repos. Run a historical scan first. You will find things.
• Establish a basic secure development checklist. Code review requirements, input validation standards, authentication and authorization patterns. This doesn’t need to be a 50-page document. A one-page checklist that your developers actually follow beats a comprehensive guide that nobody reads.

Days 61-90: Process and policy.

• Write an incident response plan. Keep it short. Who gets called, how do we communicate, what are the first steps for common scenarios (compromised account, data exposure, ransomware). Run a tabletop exercise against it. A plan that’s never been tested is a wish, not a plan.
• Draft core policies. Acceptable use, access control, data classification, incident response. These don’t need to be perfect. They need to exist, be reasonable, and be communicated to your team.
• Set up employee security awareness. Not a boring annual training. A short onboarding module, periodic phishing simulations, and a culture where people feel comfortable reporting suspicious activity without fear of looking stupid.

How to Prioritize When Everything Feels Urgent

Everything will feel urgent. It won’t all be urgent.

Use a simple framework: what is the most likely thing to cause the most damage in the next 90 days? Do that first.

A missing privacy policy is a compliance gap, but it’s probably not going to cause a breach next month. An engineer using their personal Gmail as the root account for your AWS environment, with no MFA, might.

Also, consider external deadlines. If you have a SOC 2 audit in six months, that shapes your timeline. If a major customer contract requires specific controls by a certain date, that’s a hard deadline. These forcing functions are actually helpful. They give you permission to prioritize ruthlessly.

One more principle: fix the things that are easy and high-impact first. MFA, password managers, removing public access from cloud storage. These take hours, not months, and they materially reduce your risk surface. Quick wins build momentum and credibility with leadership.

Common Mistakes

Trying to do everything at once. You can’t implement zero-trust architecture, deploy a full SIEM, achieve SOC 2, and train your entire company in the first quarter. Pick three things. Do them well. Move on.

Copying another company’s security program. Your friend’s company did ISO 27001 first. That doesn’t mean you should. Your risk profile, your industry, your customer requirements, and your team are different. Build for your context.

Over-investing in perimeter security and ignoring identity. The perimeter dissolved years ago. Your people’s credentials are your actual attack surface. Identity and access management should be your first investment, not your firewall rules.

Not getting executive buy-in early. Security requires organizational change. Change requires authority. If your CEO isn’t visibly supporting the program, teams will treat security requests as optional. Get a 15-minute slot at the all-hands. Have leadership communicate that security is a priority, not just the security team saying it.

Treating compliance as security. Compliance frameworks are useful. They give you structure, external validation, and customer confidence. But passing an audit does not mean you are secure. Plenty of breached companies were fully compliant. Build real security first, then map it to compliance requirements.

Ignoring third-party risk. Your security program means nothing if your critical SaaS vendor gets breached and takes your data with them. Build a basic vendor assessment process. At minimum, know what data each vendor has access to and whether they have a SOC 2 report.

When to Bring in Help

Building from zero is hard, and there’s no shame in bringing in experienced people to accelerate it.

If you’re the only security person (or there’s nobody at all), consider augmenting with external senior engineers who’ve built programs before. They can do the initial heavy lifting, establish the foundation, and transfer knowledge to your team.

This is a core pattern we follow at Oblak. We embed with the team, build the program, and ramp down as internal capability grows. The goal is always to leave you with something sustainable, not something that falls apart when the engagement ends.

The worst outcome is a security program that exists only in documents. Policies nobody follows. Tools nobody monitors. Controls nobody enforces. Start small, make it real, and build from there.