Security becomes urgent before it becomes organized
The first enterprise customer sends a security questionnaire. An investor asks who owns cyber risk. A new employee needs access to several systems. A founder realizes the incident-response plan exists only in someone’s head.
Each request looks separate, so the company responds separately. Engineering answers technical questions. Operations writes a policy. A compliance platform collects screenshots. Leadership approves exceptions in chat.
Activity increases, but the company still does not have a security program.
A security program is the operating system used to understand risk, make decisions, implement controls, respond to incidents and prove what the company actually does. The goal is not to create the most documentation. It is to protect the business and make security dependable.
Start with the company, not a framework
Frameworks provide useful structure. They cannot decide what matters most to this company.
Begin with the operating environment:
- What does the company sell?
- Which customers depend on it?
- What data does it collect, process and store?
- Which systems are essential to delivering the service?
- Which third parties have meaningful access?
- Which commitments have been made in contracts?
- Which laws or sector requirements apply in the jurisdictions where it operates?
- What events could materially damage customers, revenue, operations or trust?
This context determines priorities. A business handling sensitive customer information has different immediate needs from one publishing public data. A company entering enterprise procurement has different evidence requirements from one selling directly to consumers.
The framework should organize the work—not replace judgment.
The seven foundations of a practical security program
1. Clear ownership and decision rights
Someone must own the complete program. That person does not need to perform every technical task, but they must have the authority to establish priorities, assign work, approve risk treatment and escalate decisions to leadership.
Define:
- The executive accountable for security
- Operational owners for individual controls
- The role of engineering, IT, people operations and legal counsel
- Who can accept a risk or approve an exception
- Which decisions require founder, executive or board involvement
Shared responsibility without named accountability usually means that important work waits until a customer or incident forces it.
2. An asset, data and dependency inventory
The company cannot protect what it cannot see.
Build a usable inventory of critical applications, infrastructure, endpoints, data types, vendors and owners. It should answer where important data enters, where it is stored, who can access it and what the company depends on to operate.
Do not aim for theoretical completeness before taking action. Begin with the systems and data whose loss, misuse or unavailability would create the greatest impact.
3. A risk register tied to business impact
A risk register should support decisions, not become a spreadsheet nobody revisits.
For each meaningful risk, record:
- The scenario
- The affected asset, process or customer
- Likelihood and potential impact
- Existing controls
- Remaining exposure
- Owner
- Treatment decision
- Target date and status
Use language leadership can act on. “Weak access control” is abstract. “Former employees may retain access to customer systems because offboarding is manual” creates a clear decision.
4. A prioritized control baseline
The baseline is the minimum set of practices the company commits to operating consistently.
It commonly includes:
- Identity and access management
- Multi-factor authentication
- Joiner, mover and leaver processes
- Secure configuration and change management
- Vulnerability and patch management
- Backup and recovery
- Logging and monitoring
- Vendor risk management
- Secure software development
- Data handling and retention
- Incident response
- Security awareness
The NIST Cybersecurity Framework 2.0 organizes security outcomes across Govern, Identify, Protect, Detect, Respond and Recover. It can help ensure the program covers the complete lifecycle without prescribing one implementation for every company.
Prioritize controls by risk reduction, customer demand, implementation effort and operational dependency.
5. Policies that describe reality
A copied policy creates risk when it promises controls the company does not operate.
Policies should establish intent, scope, ownership and required behavior. Procedures should explain how the work is performed. Evidence should show that it happened.
Keep the set small enough to maintain. Common starting policies include information security, access control, incident response, acceptable use, vendor management, data handling, business continuity and secure development.
Write them around actual systems and responsibilities. Approve them through the correct authority, communicate them to the people affected and review them when the environment changes.
6. Incident response that can be used under pressure
The company needs more than a policy saying it will respond.
Define:
- How an incident is reported
- Who leads the response
- Who has authority to contain systems
- How severity is assessed
- Which internal and external parties are contacted
- How evidence and decisions are recorded
- How notification obligations are evaluated
- How the business recovers and learns
Test the plan with a realistic tabletop exercise. A short simulation will expose missing contacts, unclear authority and technical dependencies faster than another round of document review.
7. Evidence and operating cadence
Controls must continue after the initial project.
Create a repeatable rhythm for access reviews, vulnerability remediation, vendor reviews, policy updates, risk decisions, incident exercises and leadership reporting. Assign evidence owners and define where records are stored.
The evidence should help the company operate and answer customers—not exist only for an audit.
What to build first
A first phase should reduce immediate business risk and create visibility.
First 30 days: establish the current state
- Confirm objectives, customer commitments and applicable requirements
- Identify critical systems, data and vendors
- Review access, backups, logging and incident readiness
- Create the initial risk register
- Assign owners and escalation paths
- Identify urgent gaps that could block a deal or create material exposure
Days 31–60: implement the baseline
- Address the highest-priority control gaps
- Write policies that reflect the operating environment
- Formalize onboarding, access changes and offboarding
- Establish vulnerability and vendor-management workflows
- Build the incident-response plan
- Begin collecting evidence
Days 61–90: prove and operationalize
- Test incident response and recovery
- Run access and control reviews
- Prepare the reusable customer assurance package
- Define leadership reporting
- Create the longer-term roadmap, budget and resource plan
- Transfer recurring responsibilities to internal owners
This is a representative first phase, not a promise that every security program or certification can be completed within 90 days.
Common mistakes
Buying software before assigning ownership
A platform can collect evidence and automate workflows. It cannot decide which risks the company should accept or ensure that people perform the controls.
Treating certification as the security strategy
An audit can provide valuable assurance. Passing an audit does not remove the need to manage changing threats, products, vendors and business priorities.
Copying an enterprise control set into a small team
Controls that exceed the company’s capacity will be bypassed or performed only before an audit. Design the program so it can operate every week.
Leaving security with engineering by default
Engineering owns important technical controls. It should not automatically own contracts, policy, risk acceptance, workforce processes and board communication.
Making claims before collecting evidence
Security questionnaires and sales commitments should describe the current state accurately. A roadmap is not an implemented control.
Which operator should own the work?
Fractional CISO
Best when the company needs executive accountability, risk decisions, leadership communication and a security strategy connected to business priorities.
Security Program Lead
Best when the direction is understood but the company needs hands-on ownership of implementation across teams.
GRC Lead
Best when the immediate constraint is translating requirements into controls, evidence, policies and audit or customer readiness.
The mandate may involve all three capabilities. The binding constraint should determine the operator profile.
Example mandate: build the security program
Outcome: Establish a risk-based security program that supports current customer requirements and can scale with the company.
Initial work: Map the operating environment, critical assets, data, contractual commitments, applicable jurisdictional requirements, current controls and material risks.
Execution: Assign ownership, implement the priority control baseline, establish policies and procedures, prepare incident response, create evidence and lead the operating cadence.
Success measures: Critical risks have owners and treatment plans; priority controls operate consistently; customer questions can be answered accurately; incidents have a tested response path; leadership receives useful reporting; recurring work has internal owners.
The program should make growth easier
The best security program does not sit beside the business. It helps the company enter larger accounts, make faster decisions, respond confidently and avoid rebuilding the same evidence for every request.
Build enough structure to make security reliable. Then evolve it as customers, products, jurisdictions and risks change.