A practical approach to building an ISMS without unnecessary documentation

Implementing ISO/IEC 27001 does not mean creating hundreds of policies, procedures and spreadsheets.

For a startup, the objective should be to build a practical Information Security Management System (ISMS) that fits the way the company actually operates.

ISO/IEC 27001:2022 is designed to be applicable to organizations of different sizes and sectors. ISO also provides a practical implementation guide specifically for SMEs, recognizing that smaller organizations may have limited resources and need a scalable approach.

The key principle is simple:

Document what needs to be documented. Implement what needs to be implemented. Keep evidence that proves it is working.

1. What Does ISO 27001 Implementation Actually Mean?

ISO 27001 implementation means establishing an ISMS that enables the organization to:

Understand its information security risks
Determine what needs to be protected
Define appropriate security objectives and responsibilities
Select and implement necessary controls
Monitor whether controls are working
Review security performance
Correct problems
Continually improve the ISMS

ISO describes ISO/IEC 27001 as a framework for establishing, implementing, maintaining and continually improving an ISMS based on managing information security risks.

Therefore, implementation is not simply implementing Annex A controls.

A better implementation model is:

Business → Scope → Assets → Risks → Risk Treatment → Necessary Controls → SoA → Implementation → Evidence → Internal Audit → Management Review → Improvement

2. The Startup Problem: Too Much Documentation

Many startups approach ISO 27001 like this:

“We need ISO 27001.”

Then someone provides:

40 policies
30 procedures
20 registers
100 templates
dozens of forms

The company signs the documents, uploads them to a folder and considers the ISMS implemented.

That creates a paper ISMS.

The better approach is:

Understand the business → identify risks → implement practical controls → document important decisions → generate evidence naturally through operations.

ISO’s own guidance for implementing an ISMS emphasizes that organizations should not over-document merely for documentation’s sake. The effectiveness of the implemented controls matters more than the volume of documentation.

3. Start With the Business, Not the Policies

Before writing policies, understand the company.

For a SaaS startup, ask:

Business

What does the company do?
What information does it process?
Who are its customers?
What services are critical?
What would happen if the service went down?
What information would cause serious damage if exposed?

Technology

Where is the application hosted?
AWS, Azure, GCP or another cloud?
What databases are used?
Where is customer data stored?
How is source code managed?
How are deployments performed?
What security monitoring exists?

People

How many employees?
Remote or office-based?
Who has production access?
Who manages cloud infrastructure?
Who can access customer information?

Third Parties

Cloud provider
GitHub/GitLab
Payment providers
Email providers
HR platforms
SaaS applications
External developers
MSP/MSSP providers

This information becomes the foundation of the ISMS.

4. Step 1 — Define the ISMS Scope

Do not begin by trying to certify the entire company.

Define what the ISMS covers.

Example

Company: ABC SaaS Pvt. Ltd.

Business: B2B SaaS platform

Technology: AWS

ISMS Scope:

The development, operation and support of the ABC SaaS platform and the supporting corporate environment used to provide services to customers.

The scope should identify relevant:

Business processes
Information
Applications
Infrastructure
People
Locations
Suppliers
Organizational boundaries

Startup Tip

A narrow but realistic scope is generally easier to manage than an unnecessarily broad scope.

However, the scope should not exclude important activities simply to avoid addressing relevant risks.

5. Step 2 — Understand Interested Parties

Identify the people and organizations that have security expectations.

Typical startup interested parties include:

Interested Party	Example Requirement
Customers	Protect customer data
Employees	Secure workplace and personal information
Investors	Effective risk management
Regulators	Compliance with applicable laws
Cloud providers	Contractual/security requirements
Partners	Security requirements
Management	Business continuity and risk visibility
Certification body	Demonstrable conformity

Create a simple register.

You do not need a complicated database.

6. Step 3 — Identify Information and Assets

Create an asset inventory.

For an AWS SaaS startup:

Asset	Owner	Location	Criticality
SaaS Application	CTO	AWS	High
Customer Database	CTO	AWS RDS	Critical
Customer Files	Product	AWS S3	Critical
Source Code	Engineering	GitHub	High
Employee Laptops	IT	Corporate/Remote	High
AWS Account	Cloud Admin	AWS	Critical
Employee Information	HR	HR System	High
Security Logs	Security	AWS/Monitoring	High

Don’t try to create a 500-column asset register.

The purpose is to understand what needs protection and why.

7. Step 4 — Perform Information Security Risk Assessment

This is the heart of the ISMS.

For every important asset/process, ask:

What can go wrong?
What could cause it?
What would be the impact?
How likely is it?
What controls already exist?
What additional treatment is required?

Example

Asset: Customer Database

Risk: Unauthorized access

Threat: Compromised administrator credentials

Impact: Customer information disclosure

Likelihood: 4/5

Impact: 5/5

Initial Risk: 20 — Critical

Treatment: Reduce

Controls:

MFA
Least privilege
Privileged access management
Access reviews
Logging
Monitoring
Encryption

Residual Risk: Reassess after controls are implemented.

The organization should define its own risk methodology and acceptance criteria rather than assuming ISO 27001 mandates a particular numerical scoring formula.

ISO/IEC 27001 requires organizations to determine the controls necessary to reduce information security risks to an acceptable level.

8. Step 5 — Create the Risk Treatment Plan

Not every risk requires the same response.

A startup can typically choose to:

Reduce the risk
Avoid the risk
Share/transfer the risk
Accept the risk

Example

Risk	Treatment
Unauthorized AWS access	Reduce
Legacy application no longer used	Avoid
Certain supplier risks	Share/transfer where appropriate
Low-impact business risk	Accept

For every significant risk, identify:

Risk owner
Treatment decision
Required controls
Target date
Status
Residual risk

9. Step 6 — Determine Necessary Controls

This is where many startups make a mistake.

Do not simply say:

“ISO 27001 has 93 controls, so we need to implement all 93.”

Annex A is a reference set that is compared against the controls determined through the organization’s risk treatment process. ISO/IEC 27001’s Auditing Practices Group explains that organizations determine their necessary controls and compare them with Annex A to verify that necessary controls have not been omitted.

Necessary controls can come from:

Annex A
Legal requirements
Regulatory requirements
Customer contracts
Industry requirements
Business requirements
Organization-specific security needs
Other control frameworks

10. Step 7 — Build the Statement of Applicability

The SoA connects your risk assessment to your controls.

A practical startup SoA can contain:

Field	Example
Control	A.8.2
Applicable	Yes
Reason	AWS privileged access exists
Risk	Unauthorized production access
Treatment	Reduce
Implementation	IAM roles + MFA
Owner	CTO
Evidence	IAM configuration/access review
Status	Implemented
Residual Risk	Medium

The SoA should reflect what the organization actually needs and what it has implemented—not what someone copied from another company’s template.

11. Step 8 — Implement the Controls

Now move from documents to actual security.

For an AWS SaaS startup, implementation could include:

Identity & Access

MFA
SSO where appropriate
Least privilege
Role-based access
Privileged access controls
Joiner/mover/leaver process
Periodic access reviews

Infrastructure

Network segmentation
Security groups
Encryption
Secure configurations
Backup
Monitoring
Logging

Application Security

Secure SDLC
Code review
Dependency management
Vulnerability scanning
Security testing
Change management

Data Security

Data classification
Encryption
Access restrictions
Retention
Secure deletion
Backup and recovery

People Security

Background verification where appropriate
Security responsibilities
Security awareness
Confidentiality obligations
Onboarding
Offboarding

12. Step 9 — Create Only the Documentation You Need

A startup does need documented information.

But the objective is useful documentation, not documentation volume.

Core ISMS Documentation

A practical startup may need:

Governance

ISMS Scope
Information Security Policy
Information Security Objectives
Roles and Responsibilities
Interested Parties / Requirements

Risk Management

Risk Assessment Methodology
Risk Register
Risk Treatment Plan
Statement of Applicability

Operational Security

Access Control Policy/Procedure
Asset Management
Information Classification
Incident Management
Backup
Business Continuity
Supplier Security
Vulnerability Management
Change Management
Secure Development

Evidence/Records

Training records
Access reviews
Risk reviews
Supplier assessments
Incident records
Backup tests
Vulnerability reports
Security testing
Internal audit
Management review

The exact set should be based on the organization’s scope, risks and applicable requirements.

13. Policy vs Evidence

One of the most important concepts for startups is understanding the difference between a policy and evidence.

Policy

Production access must be reviewed periodically.

Evidence

Q2 privileged access review completed on 30 June 2026.

The policy explains what should happen.

The evidence demonstrates what actually happened.

During an audit, both may matter.

14. Use Existing Startup Tools as Evidence

Do not create separate paperwork when your existing systems already generate reliable evidence.

GitHub

Can provide evidence of:

Code review
Pull requests
Approvals
Change history
Repository access

AWS

Can provide evidence of:

IAM configuration
CloudTrail
Security groups
Encryption
Backup
Logging
Monitoring

HR System

Can provide:

Employee onboarding
Offboarding
Training
Employment records

Ticketing System

Can provide:

Access requests
Change requests
Incident records
Security issues

Vulnerability Management Platform

Can provide:

Vulnerability scans
Remediation
Risk ratings
Closure evidence

The goal is to make the ISMS part of normal operations.

15. Step 10 — Establish Security Processes

A startup should now operate the ISMS rather than simply preparing documents for certification.

Examples:

Monthly

Review critical vulnerabilities
Review security incidents
Review security alerts
Track risk treatment actions

Quarterly

Privileged access review
Risk review
Supplier review where required
Security KPI review
Backup restoration testing as defined

Annually

Risk assessment review
Policy review
Internal audit
Management review
Security testing
Business continuity/DR testing as appropriate

The frequency should be based on the organization’s risks and requirements rather than treating every activity as automatically annual.

16. Step 11 — Conduct Internal Audit

Before certification, perform an internal audit.

The internal audit should test:

Requirement → Implementation → Evidence → Effectiveness

For example:

Requirement

Privileged access must be controlled.

Implementation

AWS production access is restricted to authorized administrators.

Evidence

IAM configuration
MFA
Access approval
Access review
CloudTrail logs

Effectiveness Test

Select several privileged accounts and verify:

Who owns the account?
Why does the person need access?
Was access approved?
Is MFA enabled?
Is excessive access present?
Was the account included in the latest review?

This is much stronger than simply checking whether an Access Control Policy exists.

17. Step 12 — Management Review

Management needs to review the ISMS.

The review should consider information such as:

Internal audit results
Security incidents
Risk status
Risk treatment
Security objectives
KPI results
Changes affecting the ISMS
Customer/security requirements
Nonconformities
Corrective actions
Improvement opportunities
Resource requirements

The output should include decisions and actions.

18. Step 13 — Corrective Action and Continual Improvement

An ISMS should evolve.

Suppose a startup experiences a production security incident.

Don’t simply close the incident.

Ask:

Why did it happen?

Then:

Did the risk assessment identify this risk?

Was an existing control ineffective?

Was the procedure not followed?

Do we need another control?

Does the risk register need updating?

Does the SoA need updating?

This creates the improvement loop:

Incident → Root Cause → Risk Review → Corrective Action → Control Improvement → Verification

19. A Practical 90-Day Startup Implementation Roadmap

A startup can structure implementation into phases.

Phase 1 — Foundation

Weeks 1–2

Define business context
Define ISMS scope
Identify interested parties
Identify key information/assets
Identify key processes
Assign ISMS responsibilities

Output

ISMS Foundation

Phase 2 — Risk & Control Design

Weeks 3–4

Define risk methodology
Perform risk assessment
Create risk register
Define risk treatment
Identify necessary controls
Build Statement of Applicability

Output

Risk-Based ISMS Design

Phase 3 — Implementation

Weeks 5–8

Implement priority controls:

Access management
MFA
Asset management
Data classification
Supplier security
Incident management
Backup
Vulnerability management
Logging/monitoring
Secure development
Change management
Business continuity

Output

Operational Security Controls

Phase 4 — Evidence & Operation

Weeks 9–10

Collect evidence
Perform access reviews
Perform security testing
Test backups
Review suppliers
Review vulnerabilities
Run security awareness
Update risk register

Output

Operating ISMS

Phase 5 — Internal Audit & Management Review

Weeks 11–12

Internal audit
Findings
Corrective actions
Management review
Residual risk review
Final readiness assessment

Output

Certification-Ready ISMS

The actual time required varies significantly by organization, scope, maturity, resources and certification objectives; a 90-day plan is a practical example, not an ISO-mandated timeline.

20. Example: From Risk to Evidence

Consider an AWS SaaS company.

Risk

Unauthorized access to production environment.

Risk Treatment

Reduce.

Controls

Identity management
Access control
Privileged access
Authentication
Logging
Monitoring

Implementation

AWS IAM
MFA
Least privilege
Separate production roles
Quarterly access review
CloudTrail
CloudWatch

Evidence

IAM configuration
MFA report
Access approval tickets
Quarterly access review
CloudTrail logs
Monitoring alerts

Internal Audit

Auditor samples privileged users and verifies actual permissions.

Result

The organization can demonstrate not only that a policy exists, but that the security control is operating.

21. What Startups Should NOT Do

❌ Do not create policies first and risks later

Risk should drive the control environment.

❌ Do not copy another company’s ISMS

A fintech, SaaS startup and manufacturing company may have very different risks.

❌ Do not blindly implement every Annex A control

Necessary controls should be determined through the organization’s risk treatment process, then compared with Annex A.

❌ Do not create evidence just before the audit

Evidence should naturally result from operating the controls.

❌ Do not make the ISMS an IT-only project

Information security involves management, employees, HR, procurement, engineering, operations and business functions.

❌ Do not confuse certification with security

Certification evaluates conformity with the applicable requirements. It does not eliminate cybersecurity risk.

22. The Minimum Viable ISMS for a Startup

A useful way to think about implementation is:

Layer 1 — Governance

What are we protecting and why?

Scope
Policy
Objectives
Roles
Requirements

Layer 2 — Risk

What can go wrong?

Asset identification
Risk assessment
Risk treatment
Risk acceptance

Layer 3 — Controls

What are we doing about those risks?

Access
Encryption
Backup
Monitoring
Vulnerability management
Incident management
Supplier security
Secure development

Layer 4 — Evidence

Can we prove it?

Logs
Tickets
Reviews
Reports
Approvals
Training
Test results

Layer 5 — Improvement

Is it working and getting better?

Monitoring
Internal audit
Management review
Corrective actions
Continual improvement

23. The Startup ISMS Principle

A good startup ISMS should be:

Simple enough to operate.
Strong enough to manage risk.
Documented enough to demonstrate conformity.
Flexible enough to scale.

The objective is not to create the largest possible documentation library.

The objective is to create a system where:

People know what they are responsible for, risks are understood, controls are implemented, evidence is generated through normal operations, management reviews performance, and the system improves over time.

That is the difference between having ISO 27001 documents and actually implementing an ISO 27001 ISMS.

Practical Implementation Flow

1. Define Scope
↓
2. Understand Business & Interested Parties
↓
3. Identify Assets & Processes
↓
4. Assess Information Security Risks
↓
5. Create Risk Treatment Plan
↓
6. Determine Necessary Controls
↓
7. Build Statement of Applicability
↓
8. Implement Controls
↓
9. Generate & Collect Evidence
↓
10. Operate the ISMS
↓
11. Internal Audit
↓
12. Management Review
↓
13. Corrective Action & Improvement
↓
14. Certification Audit, if certification is desired

ISO/IEC 27001:2022 allows organizations to implement an ISMS appropriate to their size, structure and needs; certification is an optional separate step for organizations that choose to pursue it.

For a startup, the goal is not:

“How many ISO documents can we create?”

The better question is:

“What information security risks do we have, what are we doing about them, and can we demonstrate that those controls actually work?”