Building a Security Program From Zero

Getting hired as the first security person at a company is a specific kind of chaos. There's no ticket queue, no established tooling, and usually no budget line waiting for you. What follows is a rough map of how that first 90-180 days typically goes, and what actually moves the needle versus what just feels productive.

What "nothing" usually means

When people say a company has no security function, they rarely mean zero controls. They mean no dedicated owner. Engineering has probably enabled some basic AWS IAM policies, IT has some antivirus rolled out through an MDM tool, and someone in finance has opinions about SOC 2 because a customer asked. Your first job is inventory, not implementation. Before writing a single policy, find out what's already running: cloud accounts (and how many nobody remembers creating), SaaS tools with admin access to source code, and whether there's a single source of truth for employee offboarding. A spreadsheet is fine for this. A GRC platform is not the priority yet.

The first 30 days: visibility over control

Resist the urge to write an acceptable use policy in week one. Nobody will read it and it won't stop the actual risks. Instead, get visibility into three things:

• Identity: pull a full user list from your identity provider (Okta, Google Workspace, Azure AD) and cross-reference against HR's active employee list. You will find ghost accounts.
• Cloud footprint: run something like aws organizations list-accounts if you're on AWS, or check GCP's Asset Inventory, to see how many environments exist versus how many anyone can name from memory.
• Code and secrets exposure: run gitleaks detect or trufflehog filesystem . against your main repos. Finding a hardcoded API key in commit history from two years ago is almost guaranteed and it's a fast way to demonstrate value.

Document findings, but don't turn this into a 40-page report nobody opens. A one-page risk summary with five bullet points gets read by a CTO. A long PDF does not.

Picking your first three controls

With no headcount and no tooling budget, you can't do everything at once. Order of operations that tends to work:

1. MFA everywhere it isn't already, starting with the identity provider, then GitHub/GitLab, then cloud consoles. This alone closes off the most common account-takeover path.
2. Centralized logging for cloud and auth events. Even a free tier of a SIEM-adjacent tool, or just shipping CloudTrail/GCP audit logs to a bucket with retention, beats having nothing when an incident happens.
3. A written, short incident response plan, even if it's two pages: who gets paged, who talks to customers, who has authority to shut something down. Nobody remembers to build this until the day they need it, and by then it's too late.

Notice none of these require a large vendor contract. They require decisions and follow-through.

Getting buy-in without a security budget line

The fastest way to lose credibility as a first security hire is to show up with a wishlist of tools before showing any results. Instead, tie every ask to something concrete: "we found three IAM users with unrotated access keys from 2021" lands better than "we need a CSPM tool." Frame requests in terms engineering and finance already care about: reduced blast radius, faster audits, fewer 2 a.m. pages. If the company is chasing SOC 2 or ISO 27001, that compliance deadline is often your best leverage point for getting resources, even if compliance itself isn't the goal.

Common mistakes in the first year

Buying a expensive platform (SIEM, EDR, CSPM) before you have the process or headcount to actually operate it is the single most common waste of early budget. A $50k tool nobody tunes generates noise, not detection. Similarly, writing policies copied from a template without adapting them to how the company actually works guarantees they get ignored the first time someone needs an exception. And trying to own everything solo past the first six months is a burnout path; the moment there's traction, the next hire should usually be someone who can own detection and response so you can keep building program structure.

Security from zero is mostly about sequencing: see what exists, close the loudest gaps, build enough process that decisions don't rely on your memory, and expand from there.

If this kind of ground-level program building interests you, Korra Studio has related segments on incident response fundamentals and cloud security posture that pair well with this one.