ISO 27001 Website Security: Applying the Standard to Your Web Infrastructure
ISO 27001 compliance is increasingly the entry requirement for enterprise contracts in Europe, the Middle East, and Asia-Pacific markets. While the standard is built around an Information Security Management System (ISMS) — a holistic organizational framework — its Annex A controls map directly onto the technical configuration of your web infrastructure.
This guide focuses on the Annex A controls most relevant to website and web application security, explaining what they require technically and how to verify your implementation.
Check your compliance posture: Free ZeriFlow security scan →
ISO 27001:2022 — What Changed and What It Means for Web Security
ISO 27001 was updated to the 2022 version, which restructured Annex A from 114 controls across 14 domains to 93 controls across four themes: Organizational, People, Physical, and Technological. The Technological controls are the most relevant to website security.
Key new or strengthened controls in the 2022 revision that affect the web layer:
- A.8.9 — Configuration Management — Secure baseline configurations must be documented and maintained for all technology components, including web servers and application frameworks.
- A.8.20 — Networks Security — Network controls must protect information systems, covering firewalls, WAF deployment, and network segmentation.
- A.8.21 — Security of Network Services — Security features, service levels, and management requirements for all network services (including cloud hosting and CDN) must be identified and included in service agreements.
- A.8.23 — Web Filtering — Controls to manage access to external websites to reduce exposure to malicious content.
- A.8.26 — Application Security Requirements — Information security requirements must be identified and specified when developing or acquiring applications. This is the web application development control.
- A.8.28 — Secure Coding — Secure coding principles must be applied to software development.
Annex A.8.24 — Cryptography: TLS and Encryption in Transit
The cryptography control requires a policy on the use of cryptographic controls, including key management. For a website, this translates to:
Encryption in transit policy — Every connection to your web application must use TLS. The policy must define minimum acceptable protocol versions (TLS 1.2+) and cipher suites. The policy must be documented and implemented.
Certificate management — Certificates must be issued by trusted Certificate Authorities, renewed before expiry, and revoked when compromised. Certificate lifecycle management must be automated or have documented manual procedures with alerts.
Key management — Private keys must be stored securely (HSM, secrets manager), access must be restricted and logged, and key rotation procedures must be documented.
For web infrastructure, "applying the cryptography control" means running a configuration that an external auditor's TLS scanner would classify as secure: no deprecated protocols, no weak ciphers, valid certificates with HSTS enforced.
ZeriFlow checks every dimension of your TLS and HTTPS posture — protocol support, cipher suite ordering, HSTS configuration, and certificate validity — giving you auditable evidence of your A.8.24 implementation.
Annex A.8.26 — Application Security: Security Headers as Implemented Controls
The application security requirements control mandates that information security requirements are identified, specified, and approved when developing or acquiring applications. For existing web applications, this means demonstrating that security controls are in place and operating.
HTTP security headers are the most direct evidence of application-layer security controls. Auditors and penetration testers look for:
Content-Security-Policy — Demonstrates active management of script execution context. A CSP that restricts script sources shows that the application development process includes security requirement definition.
Strict-Transport-Security — Evidence of enforced encryption in transit at the application level, complementing the server-level TLS configuration.
X-Content-Type-Options — A trivial-to-implement header that demonstrates security requirements are considered during development.
X-Frame-Options / frame-ancestors — Demonstrates consideration of clickjacking risk, relevant to protecting users of the application.
Permissions-Policy — Demonstrates restriction of unnecessary browser API access, reducing the attack surface.
Missing headers will appear in penetration test reports (required by A.8.8 — Management of Technical Vulnerabilities) as findings that require remediation within the ISMS's vulnerability management process.
Annex A.8.8 — Management of Technical Vulnerabilities
This control requires timely identification and remediation of technical vulnerabilities. For web infrastructure:
Vulnerability scanning — Regular automated scanning of web-facing assets. The frequency should be defined in your ISMS documentation; weekly or monthly scans are common. Scans must cover TLS configuration, application vulnerabilities, and server-level issues.
Patch management — Operating system, web server, application framework, and dependency patches must be applied within a defined remediation timeline based on severity. Critical CVEs (CVSS 9.0+) typically require 72-hour remediation windows under well-run ISMS programs.
Penetration testing — Annual penetration testing of web applications is standard practice and expected by certification auditors as evidence of A.8.8 implementation.
Dependency management — Third-party libraries and dependencies must be tracked (Software Bill of Materials) and monitored for new CVEs. SCA tools automate this.
The key evidence requirement: vulnerability findings must be tracked in a register, assigned to owners, and remediated with documented timelines. Identified vulnerabilities with no remediation records are a non-conformity.
Annex A.8.15 and A.8.16 — Logging and Monitoring
A.8.15 — Logging requires that event logs recording user activities, exceptions, faults, and security events are produced, protected, and retained. For web applications:
- Authentication logs (success and failure) with timestamps and source IPs.
- Application error logs.
- Administrative action logs.
- Access to sensitive data or functionality.
Logs must be protected from tampering (append-only or WORM storage, restricted access) and retained for the period defined in your ISMS (typically one to three years for general operations).
A.8.16 — Monitoring Activities requires that networks, systems, and applications are monitored for anomalous behavior. Effective monitoring includes:
- Real-time alerting on authentication failures above threshold.
- Alerts on unexpected changes to web application configurations.
- Uptime monitoring with alert escalation paths.
- Regular review of access logs for anomalous patterns.
Annex A.5.24 — Incident Management: What Happens When Something Goes Wrong
A.5.24 through A.5.28 define the incident management lifecycle. For web security:
- A.5.24 — Incident management responsibilities and procedures must be planned and prepared.
- A.5.25 — Security events must be assessed and classified.
- A.5.26 — Incidents must be responded to per documented procedures.
- A.5.27 — Lessons learned from incidents must be used to improve controls.
The web-layer implication: if your monitoring detects a web application compromise, a certificate expiry causing downtime, or a data exposure through a misconfigured endpoint, your response must follow a documented procedure. Improvisational incident response is a non-conformity under ISO 27001.
Using ZeriFlow for Continuous ISO 27001 Technical Verification
ISO 27001 certification does not end at the initial audit — your certificate requires annual surveillance audits and a three-year recertification cycle. Controls must be continuously operating, not just implemented at audit time.
The web security controls auditors verify most frequently during surveillance: - TLS configuration (A.8.24) - Certificate validity and management (A.8.24) - Security header implementation (A.8.26) - Vulnerability scanning cadence (A.8.8) - Change management for web infrastructure (A.8.9)
ZeriFlow provides the continuous external scanning layer for all of these — running the same checks a certification auditor's tooling would run, giving you evidence of ongoing control effectiveness that you can present at surveillance audits.
FAQ
Q: How long does ISO 27001 certification take?
A: Typically 6–18 months for initial certification, depending on organization size and existing security maturity. The process involves: gap analysis, ISMS design and documentation, control implementation, internal audit, management review, and Stage 1 and Stage 2 external audits. Stage 1 reviews documentation; Stage 2 verifies implementation. Certification is issued by an accredited certification body (not ISO itself).
Q: Is ISO 27001 required by law anywhere?
A: Not universally, but it is increasingly referenced in regulation. The EU's NIS2 Directive (effective October 2024) requires risk management measures that align closely with ISO 27001 controls for critical infrastructure operators. DORA (Digital Operational Resilience Act) for financial services requires ICT risk management frameworks that ISO 27001 can satisfy. In the UK, some government contract frameworks reference ISO 27001 as a qualifying standard.
Q: Can a small company (under 50 employees) get ISO 27001 certified?
A: Yes. ISO 27001 scales to any organization size. Small companies typically have a simpler ISMS scope, fewer processes to document, and a faster audit cycle. The main challenge is resourcing: maintaining an ISMS requires dedicated ownership. Many small companies hire a fractional CISO or use a managed service to maintain the ISMS between audits.
Q: How does ISO 27001 differ from SOC 2?
A: ISO 27001 produces a certificate issued by an accredited body, recognized globally, with a public register of certified organizations. SOC 2 produces an auditor's opinion report (not a certificate), is primarily used in North American markets, and is not publicly verifiable. ISO 27001 has a defined control set (Annex A) that must be addressed; SOC 2 gives more flexibility in control selection. Many companies maintain both: ISO 27001 for international and EU customers, SOC 2 for US enterprise procurement.
Q: What is the scope of an ISO 27001 ISMS for a SaaS company?
A: The ISMS scope defines which assets, processes, and systems are included in the certification. For a SaaS company, the typical scope includes the production environment, the systems used to build and deploy the product (CI/CD, development tools), and the organizational processes that support them. The scope does not have to include the entire organization — you can scope to a specific product or service — but the boundary must be clearly documented and defensible.
Conclusion
ISO 27001 applied to website security comes down to a handful of verifiable technical controls: cryptographic controls enforcing TLS 1.2+ with documented key management, security headers demonstrating application-layer control, vulnerability scanning on a defined cadence, tamper-evident log retention, and documented incident response procedures.
The distinction from a compliance checkbox exercise is continuous operation: the controls must run every day, evidence must accumulate, and deviations must be detected and remediated. Automated external scanning is the most reliable way to ensure your web-facing controls remain in the state your certification body verified.