What does a first security hire look like?
There's a variety, but it really depends on what you're looking for
Disclaimer: Opinions expressed are solely my own and do not express the views or opinions of my employer or any other entities with which I am affiliated.
I’ve intentionally made all of my posts free and without a paywall so that my content is more accessible. If you enjoy my content and would like to support me, please consider buying a paid subscription:
I’ve been getting a ton of questions lately about what a first security engineer should do. It’s a common enough question now that I figured I’d turn my “first pass” answer into a post. This is using my newsletter to scale myself and provide broader access to my thoughts and advice, which is the goal!
You might wonder why this question is coming up so often. I think it’s because many of these new AI companies are reaching velocity. They’re starting to sell into large enterprises, and the security debt is beginning to hit an inflection point, not necessarily because of a major breach. In fact, security isn’t just about breaches and protecting against adversaries. It’s deeply tied to operational pains, which compound at higher velocity.
For example, if everyone has admin access or push access to main, you’ll eventually see an outage. That might just be a well-meaning engineer deploying something without review. Now imagine that same access in the hands of a malicious actor. Operational risk and security risk are often the same thing: one is accidental, the other is adversarial.
So yes, you need a security hire. But what kind? And why?
First: Don’t Hire to “Do Security”
Let’s start with some bad reasons to make your first security hire:
You want to “prevent a breach.” That’s not a job description. A good security hire will reduce your risk, but giving them an undefined mandate sets them up to fail.
You want to “build a security org.” Great, but the first hire should be solving specific problems, not just building out headcount.
Vague goals like these often reflect a lack of clarity about what problems actually need solving. Security adds friction by default. If you don’t have clear goals, you’ll end up with even more friction and less progress.
If you’re unsure what you need, two things can help:
A strong engineering leader who understands what pain points a security hire could address.
Talking to potential hires about how they’d approach the role. Don’t ask prescriptive questions, but let them pitch you their plan. Their framing will tell you a lot about how they will approach the role and whether it fits your needs.
This is similar to how you hire a founding engineer, and it’s how you should hire a founding security engineer, too.
The first security hire will shape how security works at your company for the next few years. That doesn’t mean they’ll define all your policies forever, but they will define your defaults, whether security is a blocker, an advisor, or an enabler. It will define the security culture and how relationships will be built with other teams, i.e., it can be a problematic organization or a high-leverage one.
That’s why it’s important to match the persona to your current needs and be deliberate about hiring the right fit. Let’s look at a few common ones.
Common First Security Hire Personas
1. The Compliance Operator
This person is useful if you’re selling to large enterprises and need help with SOC 2, ISO, or FedRAMP. These are operationally heavy and confusing if you’ve never done them before. If you’re not selling to enterprises, you probably don’t need this hire.
The downside: this person is often focused on identifying and surfacing risk, but they may not have the engineering skills to fix it. Essentially, this person is a compliance and risk manager, which is definitely a type of security person, but if not managed carefully, this can create friction with product and infrastructure teams. It’s important to know if this is what you want or your highest priority. This will also set the culture that security is viewed as an operational role rather than an engineering one, and the corresponding culture and relationships will result. I’ve written in the past that it’s ok to have an operational security team, but you just have to know what you’re signing up for.
2. The Cloud Security Engineer
This engineer is often a former DevOps or infrastructure engineer who pivoted into security. This person will likely be great at working with infra teams and solving common problems related to access control, secret management, and environment segmentation. It’s a good fit if your pain is infrastructure-related or if your current infrastructure team is doing a lot of the core security work, which is common. Most companies worry about their infrastructure being hacked more than their applications in the beginning.
3. The Security-Minded Software Engineer
This is a rare persona and hard to hire, but ideal. This person can go deep on both product and infrastructure issues. They can often write the PR to fix something themselves. In early-stage startups, this is highly valuable. This person can both find and fix problems. It’s exactly what you need to make progress on your security issues, and you can likely repurpose this person for general software engineering issues.
However, they’re hard to find and even harder to retain. But if you get one, they can lead, execute, and influence other engineers with credibility. For those who read my newsletter more regularly, this is the persona I’m most bullish on.
So, who should you hire?
It depends on your company’s needs and go-to-market motion. If you’re selling to the government, you’ll need compliance. If you’re a dev tool, you’ll probably want the software engineer. If your pain is infra-related, start with cloud security.
But regardless of the persona, what matters most is fit, i.e., someone who understands your company’s maturity, can plug into how your engineering org works, and help define the culture of security, not just the processes.
One thing I’ll add, while I advocate for engineering-led security, I understand that it’s not always possible to find that perfect fit immediately. You can start with someone else who solves a pressing problem, as long as you’re intentional about the long-term shape of your security team. This is more important than anything else!
The first hire doesn’t need to be perfect. But they do need to align with your company’s stage and goals. Hiring vaguely “for security” is how you get someone who writes policies nobody reads or files bugs nobody fixes. Hiring with intent, i.e., for a specific pain or strategic outcome, is how you get someone who enables velocity and earns trust. Also, it’s important to understand the consequences of your hire and how it will shape the culture of both the security and engineering organizations.
Anyway, this is meant to be a general article with some thoughts I’ve been sharing with other startup founders and leaders. Feel free to reach out if you want to hear more about my specific experiences and some context-specific thoughts on your security situation!
Also, if you’re interested in what it’s like to run a modern security organization efficiently, consider reading this guest post by Maya Kaczorowski.
