You are the first security hire. Possibly the only one. There are 120 engineers, no AppSec program, a compliance deadline someone mentioned in the interview, and a scanner that somebody enabled in 2023 which now has 4,000 open findings nobody has read.
The instinct is to start fixing. Do not. The first 90 days decide whether you spend the next two years as a blocker people route around, or as the person whose reviews engineers actually want. This is a plan for getting that right, written for the solo security engineer at a 50 to 300 person company.
Days 1 to 30: find out what is true
Resist every request to opine until you can answer four questions. Write the answers down, because you will need them in month three when someone asks why you prioritised what you did.
What do we run, and where? Not the architecture diagram, the real inventory. Repositories, cloud accounts, domains, SaaS applications holding company data, third-party integrations with production access. In most companies this list has never existed and assembling it is the single highest-value thing you do all quarter.
What would actually hurt? Rank by blast radius, not by CVSS. The customer database, the deploy credentials, the admin panel that predates SSO, the CI system that can push to production. Five things, ordered.
Who already does security work? There is always someone. The backend engineer who reviews auth changes, the platform engineer who set up the VPC properly, the person who quietly fixed the S3 bucket. Find them. They are your program.
What is forcing the timeline? A SOC 2 audit, a customer contract, a board requirement, a regulation. There is nearly always one, and it determines what you are allowed to spend the year on regardless of what the risk ranking says.
Talk to twenty engineers in these four weeks. Ask what they think is broken and what security has cost them in wasted time. You will get your roadmap and, more importantly, a reputation as someone who asked first.
Days 31 to 60: fix the things nobody will argue about
Now do work. Pick items that are unambiguously good, cheap, and visible, because your credibility budget in month two is small and you are about to spend it.
The reliable set:
- MFA everywhere, enforced, no exceptions list. If there is an exceptions list, it contains an executive and a service account, and both are the problem.
- Kill shared credentials. The shared admin login, the API key in the team password note, the deploy key three people have.
- Secrets out of the repository. Scan history, not just the working tree. Rotate what you find, because a secret in git history is disclosed, not hidden.
- Branch protection on anything that deploys. Review required, force push disabled, CI required.
- Offboarding that actually removes access. Test it against someone who left six months ago. The result is usually instructive.
- One incident response runbook. Two pages: who to call, how to declare, where the log is, who talks to customers. Not a policy. A runbook.
Every one of these is defensible in a sentence, none requires an engineering roadmap slot, and together they close the majority of the paths that actually get small companies breached.
What to leave alone: the 4,000 findings. They will still be there. Touching them now means spending month two arguing about severity with people who do not yet trust you.
Days 61 to 90: make the backlog tractable
Now the scanner. The number is not real, and your first job is to say so with evidence.
The ordering that works, applied in sequence, each step shrinking what the next one has to consider:
- Is it in something we deploy? Findings in test fixtures, examples, and archived repositories are not production risk. This alone typically removes a third.
- Is it known to be exploited? The CISA KEV catalogue is a short list of vulnerabilities with observed exploitation. Anything on it is not a backlog item, it is this week's work.
- Is exploitation likely? EPSS gives a probability rather than a severity. Most high-CVSS findings have a very low EPSS score, and that gap is where the noise lives.
- Is the vulnerable code reachable? Whether your application ever calls the affected function. This is the biggest single reduction available and the one that needs tooling to answer at scale.
What comes out the other end is usually one or two percent of the original number, and it is a list an engineering team will work. Present it that way: not "we have 4,000 vulnerabilities" but "we have 38 that matter, here they are, here is why the rest do not."
Then fix the inflow. A backlog that took three years to build will rebuild itself unless new findings are gated at the pull request. Block on the narrow set that matters, warn on the rest, and never turn on a gate you have not first run in warn mode for a fortnight.
The three mistakes that define the job
Becoming the ticket queue. If every security decision routes through you, you are the constraint, and at 1 to 120 you will lose. Push decisions into defaults, gates, and templates. A secure-by-default service template prevents more than a year of code review.
Optimising for the audit. Compliance work is real and you will do it, but a program built only to pass an audit produces a company that passes audits. Do the control because it reduces risk, then collect the evidence as a side effect.
Announcing a policy nobody asked for. The fastest way to become the person engineers route around is to publish a standard in month one that blocks a workflow you did not know existed. Ask before you mandate.
The concession
This plan is biased toward breadth. A specialist would say you should have done a threat model, and they would be right that you are making risk decisions on incomplete information.
That trade is deliberate. At one security person per hundred engineers, coverage of the obvious beats depth on the interesting, because the incidents that actually happen at this size are stolen credentials, exposed storage, and an unpatched internet-facing service. Do the depth work in year two, once the floor is in place.
The implication
The job is not to secure the company in 90 days. It is to build the smallest structure that keeps working when you are on holiday: an inventory that stays current, defaults that are safe, gates that fire without you, and a short list of people who do security work in their own teams.
Everything after that is easier. Almost nothing is possible before it.
