ISO 27001 Web Security Readiness Guide

ISO 27001 requires a complete, accurate inventory of all information assets. For web-facing systems this means enumerating every application, API endpoint, subdomain, and supporting service before any other control can be applied. An incomplete inventory leads to unmanaged attack surface — a gap that auditors and attackers alike will find.

• List every domain and subdomain your organisation owns or operates, including staging, development, and partner-managed properties.
• Document each web application's purpose, owner, data classification, and technology stack (language, framework, CMS, server).
• Record all external APIs, SaaS integrations, and third-party scripts loaded by your web properties.
• Assign a named asset owner responsible for each web property — ISO 27001 requires ownership to be explicit.
• Store the inventory in a version-controlled location (e.g., a CMDB, wiki, or spreadsheet with change history) and commit to a review cycle of at least every six months.
• Use DNS enumeration techniques and certificate transparency logs to discover shadow IT subdomains not in your official records. Sensagraph continuously monitors your external attack surface and can surface previously unknown subdomains.

The risk assessment is the heart of any ISO 27001 ISMS. For web assets, you must identify realistic threats, evaluate existing controls, and decide which residual risks are acceptable. Auditors will scrutinise your methodology for rigour and consistency.

• Choose and document a risk assessment methodology (e.g., asset-based or scenario-based) and apply it consistently across all web assets.
• Identify threat scenarios relevant to web applications: injection attacks, authentication bypass, data exfiltration, DDoS, supply-chain compromise, and misconfiguration.
• Rate each risk by likelihood and business impact, producing a risk score. Use a consistent scale (e.g., 1–5 × 1–5 matrix).
• Map existing controls to each risk and calculate residual risk after controls are applied.
• Produce a formal Risk Treatment Plan (RTP) that specifies, for each unacceptable residual risk, whether you will mitigate, accept, transfer, or avoid it — with named owners and target dates.
• Include web-specific assets such as SSL/TLS certificates, admin panels, authentication mechanisms, and user data stores in the risk register.
• Review and update the risk assessment at least annually and after any significant change to web infrastructure.

All data in transit between users and your web applications must be encrypted. Weak TLS configurations — outdated protocol versions, weak cipher suites, expired certificates, or missing HSTS — are among the most commonly cited audit findings and represent a direct risk to confidentiality and integrity.

• Redirect all HTTP traffic to HTTPS with a permanent (301) redirect — never serve any content over plain HTTP.
• Disable TLS 1.0 and TLS 1.1 on all web servers; support only TLS 1.2 and TLS 1.3.
• Disable SSLv3 and any export-grade or NULL cipher suites. Prefer ECDHE key exchange and AES-GCM ciphers.
• Ensure all TLS certificates are valid, issued by a trusted CA, and not expiring within 30 days. Automate renewal with Let's Encrypt or your PKI solution.
• Enable HTTP Strict Transport Security (HSTS) with a max-age of at least 31,536,000 seconds; add includeSubDomains and submit to the HSTS preload list once stable.
• Enable OCSP stapling on your web server to provide efficient certificate revocation checking.
• Test your TLS configuration against known weaknesses (BEAST, POODLE, ROBOT, DROWN, Heartbleed) and document results as evidence. Sensagraph automatically checks TLS protocol versions, cipher suites, and certificate validity.

ISO 27001 Annex A controls on identity and access management apply directly to web application authentication. Weak or inconsistent access control is consistently the top cause of data breaches in web applications.

• Enforce multi-factor authentication (MFA) on all administrative interfaces, CMS backends, hosting control panels, and any application handling sensitive data.
• Apply the principle of least privilege: each user role should have the minimum permissions required to perform its function. Document role definitions formally.
• Remove or disable all default credentials on web servers, CMSs, databases, and management consoles before going to production.
• Implement account lockout or progressive delay after a configurable number of failed login attempts (typically 5–10) to mitigate brute-force attacks.
• Set secure session management: use cryptographically random session tokens, set Secure, HttpOnly, and SameSite=Strict (or Lax) cookie flags, and enforce session timeouts after inactivity.
• Implement a formal access review process — review and recertify all web application user accounts at least every six months, revoking access for departed staff immediately.
• Log all authentication events (successful and failed logins, password changes, MFA events) and retain logs for the period defined in your log retention policy.

HTTP response headers are a low-cost, high-impact security control. Missing or misconfigured headers expose users to clickjacking, cross-site scripting, MIME-sniffing attacks, and information leakage. Auditors and penetration testers routinely check for them.

• Content-Security-Policy (CSP): Define an explicit allowlist of trusted content sources. Start with a report-only policy to avoid breaking changes, then enforce it. Avoid unsafe-inline and unsafe-eval where possible.
• X-Frame-Options: Set to DENY or SAMEORIGIN to prevent clickjacking (or use CSP's frame-ancestors directive).
• X-Content-Type-Options: Set to nosniff to prevent MIME-type sniffing.
• Referrer-Policy: Set to strict-origin-when-cross-origin or stricter to limit referrer information leakage.
• Permissions-Policy: Restrict access to browser features (camera, microphone, geolocation) your application does not need.
• Remove or obscure server-identifying headers such as Server, X-Powered-By, and X-AspNet-Version to limit information disclosure.
• Validate header configuration using automated scanning and document the results as evidence of the control. Sensagraph checks all major HTTP security headers on every scan.

ISO 27001 Annex A 8.28 (Secure Coding) requires that software development follows secure coding principles. The OWASP Top 10 is the de facto reference for critical web application risks and maps directly to this control. Your auditor will expect evidence that these risks have been systematically addressed.

• Injection (SQLi, command injection, LDAP injection): Use parameterised queries and prepared statements. Never concatenate user input into queries or shell commands. Validate and sanitise all input on the server side.
• Broken Access Control: Enforce authorisation checks on every server-side action. Deny by default; never rely solely on UI-level hiding of functionality.
• Cryptographic Failures: Identify all fields containing sensitive data (passwords, PII, payment data) and ensure they are encrypted at rest with modern algorithms (AES-256, bcrypt/Argon2 for passwords).
• Cross-Site Scripting (XSS): Encode all output in the correct context (HTML, JavaScript, URL). Use templating engines with auto-escaping enabled. Apply a strict CSP.
• Security Misconfiguration: Disable directory listing, remove sample files and default pages, disable unnecessary HTTP methods (PUT, DELETE, TRACE), and keep all software patched.
• Vulnerable and Outdated Components: Maintain a software bill of materials (SBOM) for all dependencies and monitor for CVEs. Update or replace vulnerable libraries promptly.
• Insecure Deserialization: Avoid deserialising data from untrusted sources where possible; if unavoidable, validate and sign serialised objects.
• Incorporate OWASP Top 10 testing into your SDLC via code review, SAST, and DAST. Document findings and remediation as evidence for Annex A 8.25 and 8.28.

ISO 27001 Annex A 8.8 requires that technical vulnerabilities are identified and managed in a timely manner. For web assets, this means running regular automated scans and maintaining a formal process for triaging, prioritising, and remediating findings.

• Run automated web vulnerability scans against all in-scope web applications at least monthly — and after every significant release or infrastructure change.
• Maintain a vulnerability register that records each finding with: date discovered, severity (Critical/High/Medium/Low), affected asset, remediation owner, target remediation date, and closure date.
• Define SLAs for remediation by severity — a common baseline is: Critical ≤ 24 hours, High ≤ 7 days, Medium ≤ 30 days, Low ≤ 90 days. Document and enforce these SLAs.
• Conduct at least one annual penetration test by a qualified third party against web-facing assets and include the report in your ISMS evidence pack.
• Subscribe to CVE feeds and security advisories for every technology in your web stack (web server, application framework, CMS, plugins, libraries).
• Track remediation progress and report vulnerability metrics (open vulnerabilities by severity, mean time to remediate) to management at least quarterly. Sensagraph provides continuous automated scanning and generates scan reports that can be stored directly as ISO 27001 evidence.

ISO 27001 requires that events are logged and that logs are reviewed to detect and investigate security incidents. For web applications, this means capturing meaningful security events, protecting log integrity, and having alerting in place for anomalies.

• Enable and centralise web server access logs, error logs, application security event logs, and authentication logs in a SIEM or log management platform.
• Log the following events at minimum: all authentication attempts (success and failure), privilege escalations, administrative actions, input validation failures, and error responses (4xx, 5xx) in bulk.
• Ensure log entries include: timestamp (UTC), source IP, user/session identifier, action performed, and outcome.
• Protect log integrity: ship logs to a write-once or remote system so they cannot be tampered with by a compromised web server.
• Define and document log retention periods in alignment with your data retention policy and any applicable regulations (commonly 90 days online, 12 months archived).
• Configure automated alerts for: repeated authentication failures (potential brute force), spikes in 5xx errors, unusual geographic access patterns, and known attack signatures (SQLi, XSS patterns in request logs).
• Conduct regular log reviews — at least weekly manual review for high-risk systems, automated alerting for critical events in near real-time.

Modern web applications rely heavily on third-party components — CDNs, JavaScript libraries, payment processors, analytics scripts, and SaaS APIs. Each integration is a potential attack vector. ISO 27001 Annex A 5.19 and 5.20 require that supplier relationships are managed and that agreed security requirements are monitored.

• Inventory every third-party library, CDN resource, and external API used by each web application. Include version numbers and the purpose of each dependency.
• Use Subresource Integrity (SRI) hashes on all externally hosted scripts and stylesheets so that tampered resources are blocked by the browser.
• Review the security posture of critical SaaS providers: check their SOC 2 / ISO 27001 certifications, breach history, and security contact information before onboarding.
• Include security requirements in contracts and service agreements with suppliers who process or can access your users' data (e.g., data processing agreements, penetration testing rights, breach notification timelines).
• Monitor third-party components for known CVEs using a software composition analysis (SCA) tool integrated into your CI/CD pipeline.
• Define a process for emergency removal or replacement of a compromised third-party component, including rollback procedures and user communication templates.
• Audit third-party access to your web systems at least annually — revoke tokens, API keys, and credentials for suppliers who no longer require access.

DNS is critical infrastructure for your web presence. DNS hijacking, subdomain takeover, and email spoofing via your domain are all realistic threats that ISO 27001 auditors expect to see mitigated through configuration management controls.

• Enable DNSSEC on your domain to cryptographically validate DNS responses and protect against cache poisoning attacks.
• Configure SPF, DKIM, and DMARC records for all domains that send email — set DMARC policy to p=quarantine or p=reject once confidence is established, to prevent domain spoofing.
• Audit all DNS records and remove stale CNAME, A, and AAAA records pointing to decommissioned or third-party services to prevent subdomain takeover.
• Restrict DNS zone management to a small number of named administrators using MFA-protected accounts. Enable audit logging on your DNS provider.
• Monitor for unexpected DNS changes using alerts from your DNS provider or an external monitoring service.
• Lock your domain registrar account against unauthorised transfers (registrar lock / transfer lock) and use a registrar that supports MFA.

ISO 27001 requires a defined incident management process. For web-facing systems, this means having a playbook for realistic web-specific incidents so your team can respond quickly and document actions for regulatory and audit purposes.

• Define what constitutes a security incident in the context of your web applications (e.g., confirmed breach, defacement, DDoS above threshold, data exfiltration, credential stuffing campaign).
• Write and maintain runbooks for the most likely web incident types: web application compromise, DDoS, accidental data exposure via misconfiguration, and third-party supply-chain breach.
• Assign roles: Incident Commander, Technical Lead, Communications Lead, and Legal/Compliance contact. Ensure all are trained and know their responsibilities.
• Establish a secure out-of-band communication channel (e.g., a dedicated Signal group or phone tree) for use when primary systems may be compromised.
• Test the incident response plan with at least one tabletop exercise per year covering a realistic web attack scenario. Document the exercise and lessons learned.
• Maintain an incident log recording every security event: date/time, description, severity, actions taken, resolution, and root cause. This log is key ISO 27001 evidence.
• Define your breach notification obligations (GDPR Article 33, sector-specific regulations) and build notification timelines into your incident runbooks.

ISO 27001 is as much about demonstrating what you do as doing it. Auditors will request documentary evidence for every control. Building good documentation habits throughout the year prevents a last-minute scramble before the audit.

• Maintain an Information Security Policy approved by senior management, reviewed annually, and available to all relevant staff.
• Produce and maintain an Acceptable Use Policy, Access Control Policy, Vulnerability Management Policy, and Incident Response Policy — each referencing the web-specific controls in this guide.
• Store all scan reports, penetration test results, risk assessments, risk treatment plans, and audit logs in a centralised, access-controlled evidence repository.
• Record the date, scope, and outcome of every security scan, review, and test. Sign off completed reviews with the responsible owner's name.
• Maintain a Statement of Applicability (SoA) that explicitly maps each Annex A control to your web environment and justifies any exclusions.
• Conduct internal audits of web security controls at least annually before your external audit. Document findings, corrective actions, and closure dates.
• Prepare a management review pack that summarises the security posture of your web assets (vulnerability trends, incident counts, SLA compliance) for leadership sign-off — required evidence for Clause 9.3.