If I Were Building a Security Program From Scratch Today...
I wouldn't start with technology. I'd start with the business.
Brian Gerard
8/25/20266 min read
My post content
I wouldn't start with technology. I'd start with the business.
If you gave me a blank sheet of paper tomorrow and asked me to build an organization's security program from scratch, I wouldn't start by buying a SIEM.
I wouldn't start with an EDR platform. I wouldn't start by writing 50 security policies. And I certainly wouldn't start by trying to implement every control in every framework.
I'd start by asking one question:
What does this business need to protect in order to survive, operate, and grow?
Everything else follows from that answer.
1. Understand the Business Before Protecting It
Before designing controls, I would want to understand some of the following points:
How does the organization make money?
What are its most critical business processes?
What data is most valuable?
Which systems are operationally critical?
What would stop the business tomorrow?
What regulatory or contractual obligations exist?
Which third parties are essential?
Where is the organization trying to grow?
This is where security programs often go wrong. We protect assets because they're technically important. But technical importance and business importance aren't always the same thing.
You cannot prioritize security without understanding what the business is prioritizing.
2. Establish Governance First
I would establish Security ownership, Executive sponsorship, Risk appetite. I would make sure that the decision-making authority is well documented and everyone knows where the buck stops. Security policies and risk acceptance would be developed in-line with business objectives.
This isn't bureaucracy for its own sake.
It's how the organization decides who is responsible for what.
NIST CSF 2.0's addition of Govern as a sixth function is particularly relevant here. NIST describes CSF 2.0 as a way to understand, assess, prioritize, and communicate cybersecurity risk, with governance addressing organizational context, risk strategy, roles, responsibilities, policies, and oversight. (NIST)
I would want governance established before the security program becomes a collection of technologies and disconnected projects.
3. Know What You Have
You can't protect what you don't know exists.
I would establish visibility into:
People → Devices → Applications → Data → Infrastructure → Cloud → Vendors
And I'd pay particular attention to unmanaged and unknown assets.
This is one area where the CIS Critical Security Controls are especially practical. CIS places Inventory and Control of Enterprise Assets as its first control, reflecting the fundamental principle that organizations need to know what they have before they can effectively protect it. (CIS)
I'd also establish ownership.
An inventory without accountability quickly becomes an expensive spreadsheet
4. Build the Identity Foundation
If I had to choose one area to prioritize early, identity would be near the top of my list.
I'd establish strong authentication practices and implement MFA as quickly as possible. Privileged access management with regular access reviews would be a no brainer and establishing strong controls around administrative accounts would also be part of the secret sauce of prioritization.
The reason is straightforward:
Identity is increasingly the front door to the enterprise.
If an attacker can convincingly become a legitimate user, many traditional perimeter defenses become considerably less useful.
5. Protect the Things That Matter Most
I wouldn't try to protect every asset equally.
I'd identify the most important assets first. I would think in this way:
Crown jewels → Critical business processes → Supporting systems → Everything else
Then I'd apply security proportional to the risk.
This is where risk-based prioritization becomes critical.
A payroll system, identity platform, customer database, manufacturing system, and employee laptop shouldn't necessarily receive identical treatment.
Security controls should reflect business consequences.
6. Establish the Security Hygiene Baseline
Before buying advanced technology, I'd make sure the fundamentals work.
That means things like secure configuration and vulnerability management should be in-place. Do we have good patch management? Is our endpoint protection up to snuff? Do we have things like network segmentation setup where appropriate, and do we have email security? Incident Response to respond to the fires and backup and recovery to get past the fires we couldn't avoid.
The CIS Controls provide a useful practical baseline here. CIS specifically describes its Implementation Groups as a way to prioritize safeguards based on organizational risk and resources, with IG1 representing essential cyber hygiene. (CIS)
That concept matters: Start with the fundamentals before chasing maturity.
7. Build Detection Before You Need It
Eventually, someone will ask:
"How do we know if we've been compromised?"
I want a good answer.
That means establishing:
Centralized logging
Appropriate telemetry
Detection use cases
Alert triage
Escalation procedures
Incident ownership
Retention requirements
Monitoring of critical systems
But there's an important caveat:
More alerts do not equal better security.
I would prioritize detection around the threats and assets that matter most.
Otherwise, the organization simply builds an expensive alert-generation machine.
9. Make Resilience Part of Security
Backups aren't merely an IT function.
Business continuity isn't merely a facilities function and disaster recovery isn't merely an infrastructure function. They're both components of organizational resilience.
I'd want to know:
What happens if identity is unavailable?
What happens if critical SaaS applications disappear?
What happens if ransomware takes out production systems?
What happens if a critical vendor is compromised?
What happens if our primary communication platform is unavailable?
Security should help the organization continue operating under adverse conditions.
10. Build Third-Party Risk Into the Program From Day One
Modern organizations don't operate alone; they operate through ecosystems. Ecosystems like Cloud providers and SaaS platforms. They work with payment processors and consultants. Organizations rely heavily on managed service providers, software vendors, and their business partners.
A security program that protects the enterprise while ignoring its dependencies is incomplete.
I'd establish a third-party risk lifecycle:
Identify → Assess → Contract → Monitor → Reassess → Offboard
And I'd prioritize vendors based on business impact rather than treating every supplier identically.
11. Treat Data as a Business Asset
I'd want to know:
What data do we have?
Where does it live?
Who can access it?
Why do they need access?
How long do we retain it?
Where does it go?
Who do we share it with?
That naturally leads into:
Data classification
DLP
Encryption
Retention
Privacy
Access governance
Data lifecycle management
And increasingly:
AI governance.
Because employees will use AI whether the security team is ready for it or not.
12. Build Security Culture Into the Program
Security awareness shouldn't consist of one annual training course and a phishing simulation.
I'd want employees to understand:
What we're protecting.
Why it matters.
What they are responsible for.
How to report something suspicious.
What happens when they make a mistake.
That last point matters.
If employees are afraid of being punished for reporting mistakes, you create an environment where incidents stay hidden longer.
Security culture should encourage reporting—not silence.
13. Measure Outcomes, Not Activity
I wouldn't build a dashboard filled with numbers simply because they're easy to collect.
I'd want metrics that answer:
Are we reducing meaningful risk?
For example:
Instead of:
"97% of endpoints have EDR."
Ask:
"What percentage of business-critical assets have effective endpoint detection and response?"
Instead of:
"We closed 4,000 vulnerabilities."
Ask:
"What is our exposure to exploitable vulnerabilities affecting critical business systems?"
Instead of:
"We conducted security training."
Ask:
"Are employees identifying and reporting suspicious activity more effectively?"
Metrics should help leadership make decisions.
14. Build the Program Around a Framework—Not Inside One
This is an important distinction.
I would absolutely use frameworks.
NIST CSF 2.0 provides a useful high-level structure for managing cybersecurity outcomes across Govern, Identify, Protect, Detect, Respond, and Recover. (NIST Publications)
CIS Controls provide more prescriptive safeguards.
Other frameworks may be necessary depending on industry, customers, contracts, or regulatory requirements.
But I wouldn't allow the framework to become the objective.
Frameworks describe the destination and provide structure.
The business determines where you actually need to go.
The First 90 Days
If I were actually walking into the organization, I'd probably divide the initial effort into three phases.
Days 1–30: Understand
Look at the business and really dive into its:
Assets
Data
Threats
Existing Controls
Material Risks
Days 31–60: Stabilize
Address the highest-impact foundational gaps. I would focus on:
Identity
Critical vulnerabilities
Backup/recovery
Endpoint security
Logging
Incident response
Critical third parties
Security governance
Days 61–90: Strategize
Build the longer-term program.
Business Strategy
Risk Profile
Current State
Target State
Security Roadmap
Measurable Outcomes
This becomes the foundation for the next 12–24 months.
What I Wouldn't Do
This might actually be one of the most interesting sections of the article.
If I were starting from scratch, I wouldn't:
Buy every security tool available.
More technology does not automatically equal more security.
Build 100 policies before understanding the risks.
Documentation doesn't protect an organization by itself.
Try to achieve every framework requirement immediately.
Maturity takes time.
Treat every vulnerability as equally important.
Risk requires prioritization.
Measure success by the size of the security team.
Headcount isn't a security outcome.
Build a security program nobody understands.
If the business doesn't understand the program, it becomes difficult to sustain.
Align security decisions with business objectives.
The Real Goal
The goal isn't to build the most sophisticated security program.
It's not to own the most security technology.
It's not to have the largest security team.
It's not to achieve the highest possible maturity score.
The goal is much simpler:
Build a security program that allows the organization to pursue its objectives while keeping risk within an acceptable range.
That's what security leadership should ultimately deliver.
If I were building a security program from scratch today, I would resist the temptation to start with technology.
I'd start with context.
I'd learn the business.
I'd understand its risks.
I'd identify what matters most.
I'd establish accountability.
I'd build the fundamentals.
I'd measure whether those fundamentals actually reduce risk.
And then I'd build from there.
Because the best security program isn't the one with the most controls.
It's the one that protects what matters most, responds when things go wrong, enables the business to move forward, and continuously adapts as the organization changes.
Contact
Reach out for tailored security solutions.
© 2026. All rights reserved.