You have been hired to build a security program. Maybe you are the first security hire at a Series B startup. Maybe you are a new CISO at a mid-market company that has been running on hope and compliance checklists. Maybe you are an engineering leader who just had security added to your plate because nobody else was doing it. Regardless of how you got here, the question is the same: where do you actually start?
Most companies do not have a structured offensive security program. They have a penetration test they run once a year because an auditor told them to. They have a vulnerability scanner that nobody looks at. They have a vague sense that they should be doing more, but no roadmap for getting there. The gap between "we run an annual pentest" and "we have a mature offensive security program" is enormous, and most organizations have no idea how to cross it.
This guide is the roadmap. It walks through four phases of building an offensive security program over roughly two years, from laying the foundation through reaching advanced maturity. It covers what to do, when to do it, who to hire, what to spend, and what mistakes to avoid along the way.
Why Most Companies Do Not Have a Structured Offensive Security Program
Before diving into how to build the program, it is worth understanding why so few companies have one. The reasons are predictable and almost universal.
Security was never prioritized until something forced it. For most companies, security becomes a priority when an external event demands it: a customer asks for a SOC 2 report, a compliance framework requires a penetration test, a breach makes headlines, or an investor asks about security posture during due diligence. These events create urgency but not strategy. The company reacts by buying the minimum required testing and moves on.
Nobody owns offensive security holistically. The IT team runs vulnerability scans. An external firm does the annual pentest. The developers handle code security. The compliance team manages audit requirements. Nobody is looking at the full picture and asking whether these disconnected activities actually reduce risk in a meaningful way.
The knowledge gap is real. Building an offensive security program requires a specific combination of technical depth, program management skills, and organizational influence. Most security hires come from either a deeply technical background (great at finding vulnerabilities, less experienced at building programs) or a governance/compliance background (great at frameworks, less experienced at offensive testing). Finding someone who can do both is rare.
The core problem: Companies treat offensive security as a series of disconnected events (annual pentest, quarterly scan, ad-hoc code review) rather than a continuous, integrated program. The result is gaps in coverage, findings that never get remediated, and a false sense of security based on checkbox compliance.
Phase 1 - Foundation (Months 1-3)
The first three months are about understanding what you have, what your risks are, and establishing a baseline. You cannot protect what you do not know about, and you cannot prioritize what you have not measured. Resist the temptation to buy tools or launch programs during this phase. Your job is to learn.
Build your asset inventory
This is the single most important thing you will do in the first month. You need a complete, accurate picture of every system, application, API, cloud resource, domain, and third-party integration in your environment. Most companies dramatically underestimate the size of their attack surface. They know about the primary web application and the corporate network but forget about the staging environment with production data, the legacy API that nobody maintains, the marketing site running an unpatched CMS, and the dozen SaaS tools with admin-level OAuth tokens.
- External attack surface: Enumerate all domains, subdomains, IPs, cloud resources, and externally accessible services. Tools like attack surface management platforms automate this, but a manual inventory is fine for Phase 1.
- Internal assets: Catalog internal applications, databases, infrastructure, network segments, and critical data stores. Map data flows to understand where sensitive data lives and moves.
- Third-party integrations: Document every SaaS tool, API integration, and vendor connection. Understand what access each one has and what data it touches.
- Cloud resources: Inventory all cloud accounts, regions, services, and IAM configurations. Shadow IT in cloud environments is a common blind spot.
Conduct a risk assessment
With your asset inventory complete, assess risk across the environment. This does not need to be a formal framework exercise in month one. Start with a practical, threat-driven approach: what are the most valuable targets an attacker would go after, and what are the most likely attack paths to reach them?
Rank your assets by business criticality and exposure. The customer-facing web application handling payment data is a higher priority than the internal wiki. The production AWS account with database access is more critical than the sandbox environment. This ranking drives every prioritization decision for the rest of the program.
Run your first penetration test
Your first penetration test serves two purposes. It establishes a security baseline and it generates immediate, actionable findings that demonstrate value to leadership. Scope this test against your highest-risk assets identified in the risk assessment. A focused test of your primary application and external infrastructure is more valuable than a shallow test of everything.
Choose a firm that provides detailed remediation guidance, not just a list of findings. The pentest report will become the foundation of your remediation program in Phase 2. If the report just says "SQL injection found" without explaining the root cause, the impact, and specific remediation steps, it is not useful enough.
Implement basic vulnerability scanning
Set up automated vulnerability scanning for your external attack surface and critical internal infrastructure. Weekly external scans and monthly internal scans are a reasonable starting cadence. The goal in Phase 1 is not to achieve full coverage but to establish the scanning habit and begin understanding your vulnerability landscape.
Do not get overwhelmed by scan results. The first scan will produce hundreds or thousands of findings. Triage ruthlessly. Focus on critical and high-severity findings on internet-facing assets first. Everything else can wait for Phase 2 when you have a remediation program in place.
Phase 1 deliverables: Complete asset inventory, risk-ranked asset list, first penetration test report with baseline findings, vulnerability scanning configured and running on critical assets, and executive summary of security posture for leadership.
Phase 2 - Operationalize (Months 3-6)
Phase 1 gave you visibility. Phase 2 turns that visibility into operational discipline. This is where most security programs stall because operationalizing security is harder and less exciting than finding vulnerabilities. But a vulnerability you find and never fix is worse than a vulnerability you never find, because now you have documented risk you are choosing to ignore.
Build your vulnerability management program
A vulnerability management program is the engine that turns findings into fixes. Without it, penetration test reports collect dust in SharePoint and scanner results become background noise. The program needs three components: a tracking system, remediation SLAs, and an escalation process.
Tracking system: Every finding from every source (pentests, scanners, code reviews, bug reports) goes into one system. This could be a dedicated vulnerability management platform, a Jira project, or even a well-structured spreadsheet at this stage. The point is that nothing falls through the cracks and you have a single view of your vulnerability landscape.
Remediation SLAs: Define how quickly vulnerabilities must be fixed based on severity. A reasonable starting framework:
| Severity | Remediation SLA | Examples |
|---|---|---|
| Critical | 7 days | RCE, authentication bypass, exposed credentials |
| High | 30 days | SQL injection, privilege escalation, SSRF |
| Medium | 60 days | XSS, CSRF, insecure direct object references |
| Low | 90 days | Information disclosure, missing headers, verbose errors |
Escalation process: Define what happens when SLAs are missed. First escalation goes to the engineering manager. Second escalation goes to the VP of Engineering. Third goes to the CTO. Without teeth, SLAs are suggestions. Tie SLA compliance to team health metrics and make it visible in engineering leadership reviews.
Developer security training
Security training for developers should start in Phase 2, not Phase 1. Why? Because now you have real pentest findings and scanner results from your own codebase to use as training material. Training that says "here is what SQL injection looks like in our application, here is the code that caused it, and here is how we fixed it" is ten times more effective than generic OWASP training.
Start with the OWASP Top 10 mapped to your tech stack. If you are a Node.js shop, focus on JavaScript-specific patterns. If you are running Java microservices, cover deserialization and JNDI injection. Make training practical, hands-on, and directly relevant to what developers encounter in their daily work.
Integrate testing into the SDLC
Security testing should not be a gate at the end of the development process. It should be woven into the development lifecycle at multiple points. In Phase 2, start with the highest-impact, lowest-friction integrations:
- Pre-commit hooks: Secret scanning to prevent credentials from being committed to source control
- CI/CD pipeline: Dependency scanning (SCA) to catch known vulnerabilities in third-party libraries before they reach production
- Pull request checks: Static analysis (SAST) on changed files, scoped to high-confidence findings only to avoid alert fatigue
- Pre-deployment: Dynamic scanning (DAST) against staging environments for critical applications
The key principle is to start with tools that have low false-positive rates and high signal. Developers will reject security tooling that floods them with noise. Begin with secret scanning and SCA, which have the best signal-to-noise ratio, then gradually add SAST and DAST as the team builds tolerance and trust in the tooling.
Phase 2 deliverables: Functioning vulnerability management program with tracking and SLAs, developer security training program launched, security tooling integrated into CI/CD pipeline, second penetration test to measure improvement against Phase 1 baseline.
Phase 3 - Mature (Months 6-12)
By month six, you have a foundation (asset inventory, risk assessment), an operational engine (vulnerability management, SDLC integration), and a baseline understanding of your security posture from multiple penetration tests. Phase 3 is where you shift from periodic testing to continuous security operations.
Continuous testing with PTaaS
Annual penetration testing has a fundamental flaw: it tests a snapshot of your application at one point in time. If your development team ships weekly (or daily), the application tested in January looks nothing like the application running in June. Continuous penetration testing, often delivered as PTaaS (Penetration Testing as a Service), solves this by providing ongoing testing coverage that keeps pace with development.
PTaaS models vary, but the core idea is the same: instead of a single engagement per year, security testers have ongoing access to your application and test new features, changed functionality, and emerging attack vectors continuously. Findings are reported in real time rather than in a report delivered weeks after the test. Remediation verification happens immediately rather than waiting for the next annual engagement.
The transition from annual pentesting to PTaaS is one of the most impactful upgrades you can make. It compresses the feedback loop from months to days, catches vulnerabilities before they accumulate, and gives developers immediate security feedback on their work.
Attack surface management
Your Phase 1 asset inventory was a manual, point-in-time exercise. In Phase 3, replace it with continuous attack surface management that automatically discovers, monitors, and assesses your external attack surface. Cloud infrastructure changes daily. New subdomains appear when developers spin up services. Third-party integrations come and go. Manual inventory cannot keep up.
An ASM platform continuously enumerates your external assets, identifies changes, detects misconfigurations, and flags exposures. It answers questions like: did someone just expose an S3 bucket? Is there a new subdomain running a service we do not recognize? Did a TLS certificate just expire on a customer-facing endpoint?
Red team exercises
Penetration testing evaluates technical vulnerabilities. Red team exercises evaluate your organization's ability to detect and respond to a real attacker. The distinction matters. A pentest might find that SQL injection exists in a web application. A red team exercise simulates a full attack chain: initial access through phishing, lateral movement through the network, privilege escalation to domain admin, and data exfiltration, all while testing whether your security operations team detects any of it.
Red team exercises require a more mature security program to be valuable. There is no point in testing detection capabilities if you do not have detection capabilities. By month six to twelve, you should have enough security tooling and monitoring in place that a red team exercise produces meaningful insights about your detection gaps.
Metrics and reporting
In Phase 3, you need to start measuring program effectiveness with metrics that leadership understands. The goal is to show that the security program is reducing risk over time, not just finding more vulnerabilities. Key metrics include:
- Mean time to remediate (MTTR) by severity, tracked monthly and trended over time
- SLA compliance rate by team, showing which teams are keeping up and which are falling behind
- Vulnerability density per application, normalized by codebase size or number of endpoints
- Recurrence rate: How often the same class of vulnerability reappears after being fixed, indicating whether root causes are being addressed
- Attack surface metrics: Number of external assets, exposed services, unmonitored changes detected
- Time to detection: How quickly new exposures are identified after they appear
Report these metrics monthly to engineering leadership and quarterly to the executive team. Use trend lines, not point-in-time snapshots. A MTTR of 15 days for critical findings is meaningless in isolation. A MTTR that dropped from 45 days to 15 days over six months tells a story of improvement that leadership can understand and fund.
Phase 3 deliverables: Continuous penetration testing program operational, attack surface management platform deployed and monitored, first red team exercise completed, monthly security metrics dashboard reporting to leadership.
Phase 4 - Advanced (Year 2+)
Year two is where the program reaches true maturity. The fundamentals are in place, the operational engine is running, and continuous testing provides ongoing coverage. Now you add advanced capabilities that push the program from good to excellent.
Bug bounty program
A bug bounty program invites external security researchers to find vulnerabilities in your applications in exchange for financial rewards. It provides a layer of testing coverage that no other approach can match: thousands of diverse perspectives testing your application continuously from angles your internal team and pentest firm would never think of.
Bug bounties are a Phase 4 capability for a reason. Launching a bounty program before you have a mature vulnerability management process means you will receive reports faster than you can handle them. Researchers expect timely triage, clear communication, and prompt payment. If your program cannot deliver that, you will burn your reputation with the research community quickly. Start with a private program (invite-only, 20-50 researchers) and expand to public only when your triage and remediation processes can handle the volume.
Purple teaming
While red team exercises test your defenses without the blue team's knowledge, purple teaming is a collaborative exercise where offensive and defensive teams work together in real time. The red team executes an attack technique, the blue team attempts to detect it, and both sides discuss what worked and what did not. It is the fastest way to improve detection capabilities because the feedback loop is immediate.
Purple teaming sessions focused on specific MITRE ATT&CK techniques are particularly valuable. Pick a technique, have the red team execute it in a controlled environment, evaluate whether your SIEM, EDR, and monitoring tools detect it, and tune your detections on the spot. One productive purple team day can improve detection coverage more than months of independent red and blue team work.
Threat modeling as standard practice
In Phase 4, threat modeling moves from an ad-hoc activity to a standard part of the development process. Every significant new feature, architecture change, or third-party integration goes through a threat model before development begins. This shifts security left to the earliest possible point in the development lifecycle, when changes are cheapest and easiest to make.
The key to making threat modeling sustainable is keeping it lightweight. A threat model for a new API endpoint should take 30 minutes, not three days. Use a simple methodology like STRIDE, focus on the most likely and highest-impact threats, and document the results in the same system where development work is tracked. The security champions you have trained can facilitate threat modeling sessions for their teams, scaling the practice without requiring the security team to attend every session.
Security champions program
A security champions program embeds security-minded engineers within each development team. Champions receive additional training, participate in the security community within the organization, and serve as the first point of contact for security questions within their team. By Phase 4, you have enough program maturity, training materials, and real-world findings to make a champions program effective. Champions can facilitate threat models, triage scanner findings for their team, perform security-focused code reviews, and escalate complex issues to the security team.
Phase 4 deliverables: Private bug bounty program launched, quarterly purple team exercises, threat modeling embedded in the development process, security champions program active across engineering teams.
Key Roles and When to Hire
Building a security program requires people, but the timing and sequence of hires matters enormously. Hiring too early for the wrong role wastes budget. Hiring too late creates gaps that tools cannot fill.
Your first security hire
Your first security hire should be a generalist who can operate across the full spectrum: risk assessment, vulnerability management, vendor management, security architecture guidance, and incident response. This person builds the program. They do not need to be an expert penetration tester or a compliance specialist. They need to be a builder who can assess the current state, create a roadmap, and execute across multiple domains. Hire this person before Phase 1, or during it. They drive the entire program from day one.
Building versus outsourcing
For offensive security specifically, outsourcing is the right choice for most companies through Phase 3. Building an internal offensive security team requires hiring multiple senior specialists (web app testers, network testers, cloud security experts, mobile testers) at $150,000-$250,000 per person. An external firm provides the same breadth of expertise for a fraction of the cost because their team is amortized across multiple clients.
The hybrid model that works best for most mid-size companies: an internal security team of 2-4 people owns the program, vulnerability management, security architecture, and incident response. External specialists handle penetration testing, red teaming, and specialized assessments. This gives you the program ownership and institutional knowledge of an internal team with the specialized expertise and fresh perspective of external testers.
Fractional CISO
If you are not ready to hire a full-time CISO but need strategic security leadership, a fractional CISO provides part-time executive-level guidance. They help build the roadmap, advise on budget allocation, present to the board, and provide strategic direction without the $300,000-$500,000 cost of a full-time CISO. A fractional CISO is particularly valuable during Phases 1 and 2 when the strategic foundation is being laid. By Phase 3 or 4, most companies benefit from having a full-time security leader.
Budget Allocation by Phase
Security budgets are always constrained. Knowing what to spend on and when prevents wasting money on premature investments. The following framework applies to a mid-market company (200-1,000 employees, Series B through pre-IPO).
| Phase | Budget Range | Primary Investments |
|---|---|---|
| Phase 1 | $30K - $80K | Initial pentest, vulnerability scanner license, asset inventory tooling, first security hire |
| Phase 2 | $50K - $120K/yr | Vuln management platform, SAST/SCA tooling, developer training, second pentest, remediation verification |
| Phase 3 | $150K - $300K/yr | PTaaS contract, ASM platform, red team exercise, additional security headcount, metrics/reporting tooling |
| Phase 4 | $250K - $500K/yr | Bug bounty program, purple team exercises, advanced training, security champions program, CISO hire |
These are not cumulative. Phase 3 costs include the ongoing costs from Phase 2 plus new investments. The total security budget for a mature Phase 4 program at a mid-market company typically runs $400,000-$800,000 annually, including headcount. That sounds like a lot until you compare it to the average cost of a data breach ($4.45 million according to IBM) or the revenue impact of losing a major customer due to a security incident.
Budget tip: If you can only spend money on one thing in Phase 1, spend it on a quality penetration test from an experienced firm. A good pentest report is both a risk assessment and a remediation roadmap. It identifies your most critical vulnerabilities, demonstrates risk to leadership in concrete terms, and gives you a prioritized list of what to fix first. Nothing else delivers as much value per dollar in the early stages of a security program.
Common Mistakes That Kill Security Programs
Having built and advised on dozens of security programs, the same mistakes appear repeatedly. Avoiding these pitfalls is as important as following the roadmap.
Testing without remediation processes
This is the most common and most damaging mistake. Companies invest heavily in finding vulnerabilities (pentests, scanners, code reviews) but have no process for fixing them. The result is a growing pile of known, documented vulnerabilities that never get addressed. This is actually worse than not testing at all, because now you have documented evidence of known risks you chose not to fix, which creates significant legal and regulatory liability.
Before you invest in more testing, make sure you can handle the findings you already have. If your current pentest findings are not being remediated, adding more testing will not help. Fix the remediation pipeline first.
Buying tools before building processes
The security tool market is enormous and every vendor promises to solve your problems. The temptation to buy a platform that will "automate security" is strong, especially when you are understaffed and overwhelmed. But tools without processes are expensive shelfware. A SAST tool is useless if nobody triages the results. An ASM platform is useless if nobody acts on the alerts. A vulnerability management platform is useless if there are no SLAs and no escalation process.
Build the process first, even if it runs on spreadsheets and email. Once the process is working and you understand your workflow, then buy the tool that automates and scales it. You will make a better purchasing decision because you know exactly what you need.
Compliance-only mentality
Treating security as a compliance exercise is the fastest way to build a program that looks good on paper and provides no real protection. SOC 2 compliance does not mean you are secure. PCI DSS compliance does not mean you are secure. These frameworks establish a minimum baseline, not an adequate security posture. Companies that optimize for passing audits rather than reducing risk end up with checkbox security: technically compliant, practically vulnerable.
Use compliance frameworks as a starting point and a communication tool for leadership, but build your offensive security program around actual risk reduction. The question should always be "are we reducing the likelihood and impact of a breach?" not "will we pass the audit?"
Ignoring the human element
Security programs fail when they create adversarial relationships with engineering teams. If security is perceived as the team that blocks releases, adds busywork, and criticizes code without understanding context, engineers will find ways to route around it. Build relationships with engineering leadership early. Involve developers in tool selection. Celebrate teams that remediate quickly rather than shaming teams that fall behind. Make security an enabler, not a gate.
Trying to boil the ocean
New security leaders often try to fix everything at once. They launch a vulnerability management program, a developer training initiative, a new SAST tool, a champions program, and a threat modeling practice all in the same quarter. The result is that nothing gets done well. The phased approach in this guide exists for a reason. Each phase builds on the previous one. Trying to skip phases or compress the timeline leads to a fragile program built on shaky foundations.
How Lorikeet Supports Each Phase of Your Security Program
At Lorikeet Security, we work with companies at every stage of this journey. We have seen what works, what fails, and what the common sticking points are. Here is how we support each phase:
Phase 1 - Foundation: Our penetration testing services provide the baseline assessment you need to understand your risk posture. We deliver detailed findings with actionable remediation guidance that becomes the foundation of your vulnerability management program. Our reports are built for remediation, not compliance checkboxes.
Phase 2 - Operationalize: We provide remediation verification testing to confirm fixes are implemented correctly. Our secure code review services integrate into your development workflow. We work with your team to validate that SDLC security integrations are catching the right issues.
Phase 3 - Mature: Our continuous testing and attack surface management capabilities give you the ongoing coverage that annual testing cannot provide. We deliver real-time findings, immediate remediation verification, and the continuous assurance that your security posture is improving.
Phase 4 - Advanced: We conduct red team and purple team exercises that test your organization's detection and response capabilities against real-world attack scenarios. We help train your security champions with hands-on workshops based on your own application's findings. We provide the specialized offensive expertise that complements your internal security team.
The advantage of working with a single partner across all phases is continuity. We understand your environment, your risk profile, and your team's capabilities because we have been working with you from the beginning. Each engagement builds on the last, and our testers know your application's history, architecture, and past findings.
Ready to build your offensive security program?
Whether you are running your first pentest or scaling to continuous testing, Lorikeet Security provides the expertise and partnership to build a security program that actually reduces risk. Let us help you create your roadmap.
