Building a Security Program from Scratch: A Practical Guide for Growing Companies

A customer just asked for your ISO 27001 certificate. Your board wants to know about your "security posture." A prospect's vendor questionnaire is 200 questions long, and you can't answer half of them.

You know you need a security program. You just don't know where to start. This guide walks you through it — practically, without jargon, and in the order that makes the most sense for a growing company.

Step 1: Understand What You're Protecting

Before writing a single policy, you need to know what you have. This isn't a formal asset inventory exercise — it's a practical assessment of your company's information landscape.

Ask yourself these questions:

• What data do you handle? Customer personal data, financial records, intellectual property, employee information, health data. Each type carries different regulatory obligations.
• Where does it live? Cloud services, SaaS applications, local devices, shared drives, email. Map the data flows — where it enters, where it's processed, where it's stored.
• Who has access? Employees, contractors, third-party providers, customers. Access doesn't just mean login credentials — it includes physical access to offices and devices.
• What would happen if it was lost, leaked, or unavailable? This is your informal risk assessment. The answers tell you where to focus first.

You don't need a fancy tool for this. A spreadsheet works. The point is to have a documented understanding of your environment before you start building controls around it.

Step 2: Pick Your Framework

A security framework gives you structure. Without one, you're making it up as you go — and auditors notice. The most common frameworks for EU companies:

ISO 27001 is the gold standard for information security management. It's internationally recognized, certifiable, and most customer security questionnaires map to it. If you're only going to align with one framework, make it this one.

GDPR isn't optional if you handle personal data of EU residents. The good news is that many GDPR requirements (Article 32's "appropriate technical and organizational measures") align directly with ISO 27001 controls.

NIS2 applies if you're a medium or large company in a critical sector. Its requirements overlap significantly with ISO 27001, so if you're building an ISO 27001-aligned program, you're covering most of NIS2 automatically.

Our recommendation: start with ISO 27001 as your primary framework, and map GDPR and NIS2 requirements to it. One program, multiple compliance outcomes.

Step 3: Write Your Core Policies

Policies are the foundation of any security program. They document what your organization does (and doesn't do) regarding security. An auditor's first question will always be: "Show me your policies."

You need 12 core policies to cover the essentials:

1. Information Security Policy — the top-level document. Scope, objectives, management commitment.
2. Acceptable Use Policy — rules for using company systems and data.
3. Access Control Policy — who gets access to what, and how.
4. Data Classification Policy — how different types of data should be handled.
5. Incident Response Policy — what to do when something goes wrong.
6. Business Continuity Policy — how to keep operating during disruptions.
7. Vendor Security Policy — requirements for third-party providers.
8. Data Protection Policy — GDPR-aligned privacy controls.
9. Remote Working Policy — security for distributed teams.
10. Change Management Policy — how changes to systems are controlled.
11. Password & Authentication Policy — credential and MFA standards.
12. Physical Security Policy — office and equipment security.

Each policy should be practical, not aspirational. A 50-person company doesn't need the same access control policy as a bank. Write for your actual environment and risk profile.

Common mistake: downloading generic templates and putting your logo on them. Auditors see through this immediately. Your policies need to reflect your actual company — your tech stack, your industry, your regulatory context.

Step 4: Assess Your Risks

Risk assessment sounds intimidating, but at its core it's straightforward: identify what could go wrong, how likely it is, and how bad it would be.

Start with the obvious risks for your business:

• Data breach — unauthorized access to customer or employee data
• Ransomware — systems encrypted, operations halted
• Phishing — employee credentials compromised
• Third-party breach — a vendor is compromised, your data is affected
• System outage — critical services unavailable
• Insider threat — malicious or accidental data exposure by employees
• Compliance failure — regulatory penalties for non-compliance

For each risk, rate the likelihood (low/medium/high) and impact (low/medium/high). Then decide: do you mitigate it (implement a control), accept it (the cost of mitigation outweighs the risk), transfer it (insurance), or avoid it (stop doing the risky activity)?

Document everything. A risk register doesn't need to be complex — it needs to exist and be maintained.

Step 5: Implement Controls

Controls are the specific measures you put in place to address your risks. Some are technical (firewalls, encryption), some are organizational (training, policies), some are physical (office access, clean desk).

Priority controls for most companies:

• Multi-factor authentication on all business accounts. Non-negotiable.
• Endpoint protection on all devices. Managed, not consumer antivirus.
• Email security — phishing protection, DMARC/DKIM/SPF configuration.
• Backup and recovery — automated, tested, following the 3-2-1 rule.
• Access reviews — quarterly review of who has access to what.
• Security awareness training — at least annual, with phishing simulations.
• Vulnerability management — regular scanning and patching.
• Encryption — data at rest and in transit.

Step 6: Build the Evidence

Compliance without evidence is just a claim. Every control you implement needs proof that it's working:

• MFA is enabled → screenshot of admin console showing enforcement
• Access reviews happen quarterly → signed review documents with dates
• Training is completed → completion certificates and attendance records
• Backups are tested → restoration test reports with timestamps
• Policies are reviewed annually → version history showing updates and approvals

Start collecting evidence from day one. When an auditor asks "prove it," you should be able to pull up the document within minutes, not days.

Step 7: Review and Improve

A security program isn't a project with an end date — it's a continuous cycle. ISO 27001 makes this explicit with the Plan-Do-Check-Act model. Practically, this means:

• Annual policy reviews — are your policies still accurate and relevant?
• Quarterly risk assessments — have new risks emerged? Have existing ones changed?
• Incident reviews — what happened, why, and how do you prevent it next time?
• Management reviews — is the program achieving its objectives?
• Internal audits — are controls actually being followed?

The companies that treat security as "done" after the initial setup are the ones that fail audits and suffer breaches. The ones that build review cycles into their operations are the ones that continuously improve.