There's a moment in every growing company when someone realizes they need a dedicated security person. Usually it's triggered by a customer questionnaire, a compliance requirement, or a close call that could have been a breach. Whatever the trigger, the question is the same: how do you build a security team when you've never had one?
Having helped several organizations through this process, I can tell you the common mistakes and what actually works. The path from zero to functional security team is more defined than it appears, but it's littered with traps that waste time and money.
When to Start
The honest answer is "earlier than you think." By the time you feel the need for a security team, you've already accumulated security debt. That's normal. The question isn't whether debt exists but how to address it systematically.
Rough heuristics:
- Under 20 engineers: Security is everyone's job, with one engineer designated as the security champion. Invest in secure defaults and tooling rather than headcount.
- 20-50 engineers: Your first dedicated security hire. This person should be a generalist who can assess risk, implement basic controls, and guide engineering decisions.
- 50-100 engineers: A small security team (2-4 people) covering application security, infrastructure security, and compliance.
- 100+ engineers: Specialized roles and a structured security organization.
These are approximations. A fintech with 30 engineers needs security investment earlier than a B2B content tool with 80 engineers. Threat model and regulatory environment matter more than headcount.
The First Hire
Your first security hire is the most important one. This person will define the culture, priorities, and trajectory of your security program. Get it wrong and you'll spend years recovering.
What to look for:
A generalist. Your first security hire can't be a specialist in penetration testing, or cryptography, or compliance. They need to be comfortable across the entire security landscape: application security, infrastructure, detection, incident response, and governance.
Someone who can communicate with engineers and executives. Security is fundamentally about influencing people who don't report to you. Your first hire needs to explain risk to a board member and review a pull request with a backend engineer in the same day.
A builder, not a blocker. The fastest way to kill a nascent security program is to hire someone who says "no" to everything. Your first hire should find ways to enable the business securely, not obstruct it.
Pragmatism over perfectionism. Perfect security doesn't exist. Your first hire should be able to prioritize ruthlessly, addressing the risks that matter most while accepting that some risks will be addressed later.
What to avoid:
Don't hire a CISO first. A CISO without a team is just an expensive individual contributor. Hire someone who can do the work. Hire a CISO when you have a team that needs leading.
Don't hire a compliance specialist first. Compliance is important, but it's not security. A compliance specialist will help you pass audits but might not improve your actual security posture.
Don't hire based solely on certifications. CISSP and similar certifications demonstrate knowledge breadth but don't predict job performance. Look for demonstrated ability to build and improve security programs.
The First 90 Days
Your first security hire should spend their first 90 days understanding the current state rather than implementing changes.
Month 1: Assessment
- Map the technology landscape: what's deployed, how it's built, where data lives
- Identify the crown jewels: what data and systems would cause the most damage if compromised
- Review existing security controls, even informal ones
- Understand the development process: CI/CD, deployment, code review practices
- Talk to engineers. Learn what they worry about and what they've been avoiding
Month 2: Prioritization
- Rank risks by likelihood and impact
- Identify quick wins: security improvements that can be implemented with minimal disruption
- Define the top 3-5 priorities for the first year
- Begin building relationships with engineering leadership
Month 3: Foundation
- Implement the highest-priority quick wins
- Establish basic security monitoring and alerting
- Draft an incident response plan (even a simple one)
- Present findings and priorities to leadership
Resist the temptation to start buying tools in Month 1. You can't effectively select tools until you understand the environment, and unused security tools are worse than no tools because they create false confidence.
Building the Team
After your first hire establishes the foundation, subsequent hires should address the gaps identified during assessment.
Common second and third hires:
Application security engineer. If your company's primary risk is in its software (which is true for most software companies), an AppSec engineer should be your second hire. This person reviews code, designs security features, and builds secure development practices.
Security engineer (infrastructure). If your primary risk is in your infrastructure, such as cloud misconfigurations, network security, and access control, hire an infrastructure security engineer. This person hardens your cloud environment, manages identity and access, and implements detection.
Security operations / incident response. As your environment grows, you need someone monitoring for threats and responding to incidents. This can be a dedicated hire or a responsibility shared among the team.
Hire order depends on risk. A company with a complex cloud environment but a simple web application should hire infrastructure security before AppSec. A company with a complex application handling sensitive data should hire AppSec first.
Setting Priorities
A new security team faces infinite potential work and finite capacity. Prioritization is the difference between a team that makes progress and one that drowns.
High-impact, low-effort (do first):
- Enable MFA for all accounts
- Implement secret scanning in CI/CD
- Set up basic vulnerability scanning
- Establish an incident response communication plan
- Review and restrict administrative access
High-impact, high-effort (plan and schedule):
- Implement SBOM generation across all applications
- Build a vulnerability management program
- Deploy endpoint detection and response
- Establish a security review process for new features
Low-impact, low-effort (do when convenient):
- Security awareness training
- Documentation of existing security controls
- Policy formalization
Low-impact, high-effort (defer or skip):
- Comprehensive penetration testing (before basic hygiene is addressed)
- Custom security tooling (before evaluating existing solutions)
- SOC 2 certification (before you have the controls to certify)
Common Mistakes
Buying tools before understanding problems. Vendors will happily sell you six-figure security platforms. Most of them will become shelfware if you don't have the staff to operate and tune them.
Trying to do everything at once. A three-person security team covering application security, infrastructure security, compliance, incident response, and security awareness will do none of them well. Focus on the highest risks first.
Isolating security from engineering. Security teams that operate as an external auditing function get ignored. Embed security into engineering processes, attend engineering standups, participate in design reviews, and review code alongside developers.
Hiring for the wrong stage. A startup doesn't need a GRC analyst. An enterprise doesn't need another penetration tester. Match hires to your organization's current maturity and challenges.
Neglecting metrics. Without metrics, you can't demonstrate progress or justify budget. Track vulnerability counts, mean time to remediate, coverage of security scanning, and security review adoption rates.
Scaling the Team
As the organization grows, the security team needs to evolve:
At 5-10 security engineers: Establish specializations. Have dedicated application security, infrastructure security, and detection/response functions.
At 10-20 security engineers: Introduce a security architecture function that participates in system design before code is written. Add a governance function that manages policies and compliance.
At 20+ security engineers: Consider a product security organization that embeds security engineers within product teams, supplemented by a central platform security team that builds shared tools and infrastructure.
The ratio of security engineers to total engineers varies by industry and risk profile. Common targets range from 1:50 to 1:100, but companies handling sensitive data or operating in regulated industries often have higher ratios.
How Safeguard.sh Helps
For organizations building security teams from scratch, Safeguard.sh provides immediate supply chain visibility without requiring dedicated tooling expertise. The platform deploys quickly, requires minimal configuration, and gives your first security hire an immediate view of your dependency landscape, vulnerability exposure, and supply chain risk. Instead of spending months building custom tooling, your security team can start with actionable intelligence from day one. As the team grows, Safeguard.sh scales with you, providing the SBOM management, vulnerability tracking, and compliance reporting that increasingly mature security programs require.