There's a specific kind of job offer that flatters you and traps you at the same time: come build our security program. No program yet. No team. Maybe a SOC 2 the founders bought their way through, a pile of vendor questionnaires nobody enjoys answering, and an engineering org that has been shipping just fine without you, thank you very much. You're employee number one for a function that, until last quarter, was someone's part-time worry.
The mistake almost everyone makes in that seat is to confuse urgency with velocity. They show up, run a gap assessment against a framework, and produce a heroic 47-item remediation plan that lands like a brick on the desk of every engineering lead in the building. Six weeks in, they've created a security program that exists entirely on a slide. Meanwhile the business is now slightly more afraid of them and no more secure. I want to argue for a different first 90 days — one where you reduce real risk, build credibility, and earn the right to spend money, without becoming the person who froze the company to feel safe.
Weeks 1–4: Triage, not transformation
Your first job is not to fix anything. It's to find out what would actually hurt. Standing up a program from zero is fundamentally a prioritization problem, and you can't prioritize what you can't see. So spend the first month understanding two things: what the business does to make money, and where the worst-case scenarios live.
The real mechanic here is that risk is not evenly distributed, and frameworks lie to you about that. A control checklist treats every gap as roughly equal. Reality doesn't. In a fintech, the blast radius is concentrated — production data stores, the identity layer, the CI/CD path to production, and whoever holds the keys to the cloud account. Find those first. I'd rather know precisely how someone gets from a phished laptop to customer data than have a beautifully scored maturity assessment across twelve domains.
Do this by talking to people, not by reading documents. Sit with the engineers who deploy. Ask the sales team what security questions are blocking deals. Ask finance who can move money and how. You'll learn more about your actual risk surface in ten honest conversations than in any tool's dashboard. And you'll start banking the relationships you're going to need, because nothing in security gets built by the security team alone.
Weeks 4–8: Quick wins that buy you credibility
Now you spend some of the trust you've been accumulating — carefully. Early on, your currency isn't authority, it's results that don't hurt. The fastest way to lose the room is to make your first visible act a painful one. The fastest way to win it is to remove risk people can feel without making their day worse.
Look for the high-leverage, low-friction moves. Enforcing MFA everywhere and killing the long-lived credentials nobody rotated. Turning on the logging and guardrails your cloud provider already gives you — in AWS that's the unglamorous baseline of CloudTrail across accounts, GuardDuty, Security Hub, sane SCPs, and getting off static IAM keys onto roles. None of that is exotic. Most of it is configuration, not capital. And it moves your risk needle more than a six-figure tool you haven't learned to operate yet.
The discipline is to resist the urge to buy your way out. A new leader with a budget and something to prove will reach for products, because a purchase order feels like progress. But a tool you can't operate is just risk with a renewal date. In the first 90 days, prefer the change that needs a config flag and a conversation over the one that needs a procurement cycle and an integration project. Save the buying for when you actually know what you're missing.
Budget: ask for the program, fund the foundation
Somewhere in here you'll be asked what you need. This is where most first-time security leaders either lowball themselves into irrelevance or ask for a number that gets them politely ignored. The reframe I'd offer: don't budget for security, budget for the specific risks you just mapped and the deals they're blocking.
I've written before that a mature security program is a sales asset, not a cost center — and that argument is never more useful than when you're asking for your first real budget. If you can walk into the room and say "these three controls are what's between us and the enterprise deals our sales team can't close yet," you're not asking for money to prevent a hypothetical. You're asking to unlock revenue. In a company selling into regulated buyers — and in financial services, where trust is the entire product, this is acute — provable security is a precondition for growth. Fund it like one.
Keep the first budget honest and staged. A modest amount for the foundational gaps you found, a line for the one or two hires you actually need, and an explicit promise that the bigger asks come after you've shown what the foundation buys. Leaders fund people who under-promise and then deliver visible reduction in risk. They starve people who front-load grand plans.
First hires: a builder before a specialist
When you can hire, hire for range, not depth. The instinct is to bring in a specialist — a detection engineer, a GRC lead, an appsec guru. But in a zero-to-one program, your first hire's job is everything that isn't done yet, which is to say almost everything. You want a generalist who is comfortable in the cloud console, can write enough code to automate the boring parts, can talk to an auditor without flinching, and won't panic when the answer to "what's our process for X" is "there isn't one." Specialists optimize an existing machine. You don't have a machine yet. You have a workshop.
Hire the second specialist once the shape of the work is clear and you can name the bottleneck. By then you'll know whether your real constraint is detection, compliance, or platform security — and you'll hire against evidence instead of instinct.
The takeaway
The trap of the first 90 days is believing your job is to be safe. It isn't. Your job is to let the business keep moving while it gets measurably harder to seriously hurt. Every decision you make should pass one test: does this reduce real risk without freezing the thing that pays for all of us? Triage the blast radius, ship the quiet wins, fund the foundation against revenue, and hire a builder before a specialist.
So here's the challenge. At the end of your first 90 days, you should be able to point to two lists: the risks that are smaller than the day you arrived, and the deals your security program helped move forward. If your list is mostly slideware and frameworks, you didn't build a program. You built an obstacle. Go build the program.
