Security standards for corporate CMS

#SOC 2 and ISO 27001 for corporate CMS security

SOC 2 and ISO 27001 assess the organisation that operates a system, not the theme code. Mixing the two up is how a company buys a certificate and keeps an open xmlrpc.php.

#SOC 2 Type II

SOC 2 is an AICPA examination of a service organisation. The auditor reports on the description of the system and on the suitability of design and operating effectiveness of controls against the trust services criteria, which cover five categories: security, availability, processing integrity, confidentiality and privacy (AICPA). A Type 1 report looks at controls as of one date. A Type 2 report tests whether they operated over a period.

In corporate CMS projects the SOC 2 report almost always belongs to the hosting or cloud provider. It covers their data centre, their platform and their staff. It does not cover your custom-checkout-fields plugin. The scope is written in the report, so read it before a tender answer says “SOC 2 compliant WordPress instance”.

#ISO 27001

ISO/IEC 27001:2022 requires an information security management system: asset inventory, risk treatment, supplier control, internal audits and management review. For a CMS this becomes concrete: a list of plugins and their suppliers, a patch process with deadlines, an access concept for editors and the agency, and data processing agreements with the host and CDN.

An ISO 27001 certificate on the data centre does not extend to the WordPress installation. The ISMS boundary sits where changes are approved: Git, staging, production, and who is allowed to run plugin install.

SOC 2 and ISO 27001 are common filters in enterprise and public sector procurement. They are not a legal requirement for every company website. Selling them as a property of WordPress fails the first vendor questionnaire that asks about scope.

#What NIS2 requires from a corporate CMS

NIS2, Directive (EU) 2022/2555, applies to essential and important entities in the sectors it lists, and through their contracts to the ICT suppliers that serve them. Member states had to adopt their transposition measures by 17 October 2024 and apply them from 18 October 2024 (Article 41). A WooCommerce shop does not fall under NIS2 because it takes orders. The organisation does when its sector and size put it in scope, and the agency does when a client in scope pushes the duties down the supply chain.

Article 21(2) sets the minimum measures. Each one has a direct counterpart on a WordPress stack:

Article 21(3) adds that supply chain measures must take into account the vulnerabilities specific to each direct supplier and the quality of its products and secure development practices. For a CMS, the direct suppliers are the host, the agency and every commercial plugin vendor.

Article 20 makes the management body approve these measures, oversee them and answer for infringements, and requires its members to follow training. Security of the CMS stops being a task the web team handles alone.

Article 23 sets the reporting chain for a significant incident: an early warning within 24 hours of becoming aware of it, an incident notification within 72 hours with an initial assessment of severity, impact and indicators of compromise where available, and a final report no later than one month after the notification. Article 34 sets the fine ceilings for breaching Articles 21 or 23 at a maximum of at least EUR 10 000 000 or 2% of worldwide annual turnover for essential entities, and at least EUR 7 000 000 or 1.4% for important entities, whichever is higher.

DORA, Regulation (EU) 2022/2554, has applied since 17 January 2025 to financial entities and their ICT third-party providers. A CMS run for a supervised institution sits in that regime, not only in NIS2. The overlap is covered in our NIS2 and DORA guide for WordPress.

#NIS2 transposition status by country in 2026

A directive works through national law, so the date that matters for a company is the date of its own country’s act. The status below comes from official sources checked on 12 October 2026.

The practical consequence for a group with sites in several countries: one CMS security baseline built on Article 21, and a reporting runbook per country with the right authority and form.

#What the Cyber Resilience Act means for WordPress plugins and themes

The Cyber Resilience Act, Regulation (EU) 2024/2847, was published in the Official Journal on 20 November 2024. It applies in full from 11 December 2027. Article 14 has applied since 11 September 2026: a manufacturer that becomes aware of an actively exploited vulnerability in its product must send an early warning within 24 hours and a vulnerability notification within 72 hours, through the single reporting platform to the coordinating CSIRT and ENISA.

The CRA binds manufacturers of products with digital elements, not the company that runs a website. For the WordPress ecosystem that splits three ways:

• Commercial plugin and theme vendors that place software on the EU market in the course of a commercial activity are manufacturers. Their reporting duty already runs.
• Free and open-source software is in scope only when it is made available in the course of a commercial activity (recital 18). The regulation adds a lighter role, the open-source software steward, a legal person that systematically supports free software intended for commercial use. Stewards must document a cybersecurity policy and handle vulnerabilities (Article 24).
• The site owner is a user. Its NIS2 or contractual duties stay the same, but the CRA gives it something to ask for.

The CRA defines a software bill of materials as a formal record of the components and supply chain relationships in a product (Article 3(39)). Three questions belong in every plugin purchase from now on: who receives your vulnerability reports, how fast do you ship fixes, and can you deliver an SBOM for the version we run.

#Zero trust and MFA for CMS admin access

Zero trust for a CMS means no trusted source IP: every admin session is proven again. The old model where the office VPN equals the intranet equals wp-admin is the default finding in agency networks.

#Mandatory multi-factor authentication

Password plus email link is not adequate protection for wp-admin. SMS codes fail against SIM swap. Use FIDO2 security keys, platform authenticators or passkeys. WordPress can issue Application Passwords for REST and CLI access. The WordPress security white paper describes them as revocable and not valid for logging into the admin area. They are still long-lived secrets: rotate them, bind them to a dedicated API user, and keep them out of the agency’s Git repositories.

An identity-aware proxy such as Cloudflare Access in front of wp-admin and /wp-login.php replaces the company VPN for distributed editorial teams. An allowlist of office IPs breaks the moment someone works from a train. Access tied to an identity provider (Entra ID, Google Workspace, Keycloak) keeps the policy in one place.

#Granular identity and access management

Editors need edit_posts, not install_plugins. SEO roles do not need manage_options. Shop managers need orders, not the theme file editor. DISALLOW_FILE_EDIT in wp-config.php remains the first line against a compromised editor account.

Agency access follows the same least-privilege rule as internal staff. A shared admin login used by five freelancers makes every audit trail worthless. One account per person, deactivated on the day the project ends, not renamed.

#CMS server hardening with WAF and isolated admin

A CMS is only as secure as PHP-FPM, the file tree and the path to the database. Hosting marketing copy does not replace an sshd_config.

• Immutable infrastructure. On container or image-based hosting, a new image replaces the running instance and nobody edits production over SSH. On managed WordPress plans this pattern does not exist; the substitute is no manual plugin uploads, staging identical to production, and deploys from Git only.
• WAF and DDoS protection. A WAF in front of the origin filters credential stuffing against wp-login.php, known plugin paths and XML-RPC. A WAF without a named product and a named rule set is not a control objective.
• Backend not public. In high-security environments wp-admin has no public DNS record. Access runs through a tunnel or a WireGuard VPN, and the origin talks only to the tunnel.
• PHP and core. WordPress 7.1 was released on 19 August 2026 and 7.1.3, a maintenance and security release, followed on 6 October 2026. Block xmlrpc.php unless a legitimate system needs it, and restrict the unauthenticated REST API to what the front end actually reads.

#Headless vs monolithic CMS attack surface

Headless reduces the public PHP surface. It does not remove the application.

Monolith. Every page renders PHP against the database. Plugins hook into init. Scanners probe /wp-content/plugins/ for known paths. WAF and automatic updates become survival equipment.

Headless. The CDN serves HTML, CSS and assets with no interpreter at the edge and no public database. wp-admin lives on a private network or behind an identity-aware proxy. The remaining surface sits on the origin: REST, webhooks, cron and Application Passwords. A leaked Application Password used against /wp-json/ is still an incident.

For enterprise procurement headless is often easier to argue, because the public edge has no interpreter. The origin still needs the same controls as a monolith.

#OWASP Top 10:2025 mapped to WordPress

The OWASP Top 10:2025 is the list most tenders reference when they say “secure development”. On a WordPress stack the categories land in specific places:

A03 is new in this edition and fits WordPress closely. The plugin directory is the supply chain, and the WordPress security white paper says plainly that inclusion in the repository is not a guarantee that a plugin is free of vulnerabilities.

#OWASP ASVS 5.0 as the verification standard for CMS tenders

The Top 10 is an awareness list. When a contract needs testable requirements, the reference is the OWASP Application Security Verification Standard. Version 5.0.0 was released on 30 May 2025 and is organised in 17 chapters, among them V6 Authentication, V7 Session Management, V8 Authorization, V13 Configuration and V16 Security Logging and Error Handling.

ASVS defines three levels. Level 1 holds about 20% of the requirements, the first layer of defence. OWASP says most applications should aim for Level 2; meeting it means implementing about 70% of all requirements (every L1 and L2 item). Level 3 is for applications that need the highest assurance.

Two practical rules follow for a corporate CMS. Write “ASVS 5.0 Level 2 for custom plugins and integrations” into the contract instead of “secure according to OWASP”. And treat any “ASVS certified” badge with care: OWASP states that it does not certify vendors, verifiers or software, and that certification claims are not endorsed by OWASP.

#How the WordPress project handles core security

The WordPress Security Team has more than 50 trusted experts, including lead developers and security researchers, plus sponsored members (wordpress.org/about/security). Vulnerabilities are reported through the WordPress HackerOne programme. Only the latest version is officially supported, but fixes are backported to older branches as a courtesy so that older sites receive critical fixes through automatic updates. The team also coordinates release rollouts and WAF mitigations with large hosts and security providers.

The WordPress security white paper, last updated September 2025, documents the mechanisms a corporate reviewer usually asks about:

• automatic background updates for all minor releases, which is how security fixes reach sites without an administrator acting;
• user passwords hashed with bcrypt, with SHA-384 pre-hashing to handle bcrypt’s 72-byte input limit;
• Application Passwords, reset keys and other tokens using BLAKE2b through Sodium;
• nonces against cross-site request forgery, and APIs such as wpdb::prepare(), wp_kses() and the sanitize_*() functions for safe input and output.

That covers the core. The same white paper notes that the roughly 50,000 plugins and 4,500 themes in the directory are reviewed by volunteers before listing, with no guarantee of being free of vulnerabilities. In corporate projects the risk sits in that layer.

#How to vet and patch WordPress plugins

The most common enterprise finding in WordPress is not a zero-day in core but a plugin without a maintainer.

• Inventory before installation. No plugin without a named maintainer, an update path and an entry in the SBOM. Every payment, shipping and invoicing plugin is a supplier in the NIS2 Article 21(2)(d) sense.
• Code review for everything that does not come from the vendor through a signed update channel. Must-use plugins and agency code belong in Git, not only on the server.
• Vulnerability tracking. Patchstack, WPScan or the vendors’ advisory mails. A CVE feed without a patch deadline is decoration.
• Composer and npm. Themes with a build step pull in lockfiles. Their versions go into the same SBOM as the PHP plugins.
• Patch SLA. Critical core and gateway fixes within a documented deadline; feature updates through staging first.

The configuration layer (file permissions, wp-config.php constants, server rules) is covered step by step in our WordPress security and performance guide.

#Encrypted CMS backups and point-in-time recovery

A security plan without a tested restore is a document, not a control.

• 3-2-1. The host’s backup is copy one, often on the same platform. Copy two goes to storage at another provider or region. Copy three sits offline or in an account the production credentials cannot delete. Ransomware that holds wp-config.php and the panel password likes to delete the official backup too.
• Encryption. Backups encrypted at rest and in transit, with keys stored apart from the backups.
• RPO for shops. A daily backup is enough for a brochure site. A shop with a 24 hour RPO loses orders that may already have gone to the ERP or accounting. Hourly database dumps plus binary logs, or the host’s managed point-in-time recovery, close that gap.
• Restore tests. Restore to staging once a quarter, with a stopwatch and a written record. NIS2 Article 21(2)(c) and DORA questionnaires ask for exactly that record.

#Social engineering risk and CMS audit trails

Most wp-admin takeovers in agency projects start with an email, not an exploit. Editors and accounting are targets because they see orders, invoices and PDF plugins. A message saying “invoice export failed, log in here” against a fake login page works when MFA is missing. One phishing simulation per quarter, using the real login URL as teaching material, does more than an annual slide deck.

Audit trails. Every plugin installation, role change and gateway key change recorded with user, time, IP and object. The log is shipped out of WordPress to syslog or a SIEM, so an attacker with admin rights cannot erase it. NIS2 Article 21(2)(i) and OWASP A09 point at the same gap.

When a freelancer leaves the project, the account goes the same day. A shared password vault entry with one wp-admin password for everyone is the opposite of access control.

#Checkout plugins and payment webhooks attack surface

Catalogue pages may be cached at the edge. Checkout, wc-ajax, payment webhooks and return URLs may not, and that is where the attack surface sits.

Every payment gateway opens three things: a redirect or hosted payment field, a webhook endpoint under /wc-api/ or /wp-json/, and often a status cron. Without signature verification on the webhook, an attacker marks orders as paid. Stripe and PayPal sign their webhooks. A home-made “payment complete if GET secret=” endpoint is the classic finding.

When card fields stay with the payment provider (hosted fields or components), the merchant usually stays in the smallest PCI DSS self-assessment scope. Once a plugin writes the card number or CVC into wp_postmeta, that assumption is gone. Check the post meta keys after a test order: a token plus the last four digits is normal, a full card number means removing the gateway.

REST keys for wc/v3/orders with broad permissions give full access to customer data. One key per system (ERP, accounting bridge, shipping), read-only where possible, with an IP allowlist on the origin.

#Object cache and debug logs in shops handling payments

Redis speeds up object lookups. Unfiltered, it also stores sessions, transients and sometimes gateway responses.

• What must not stay in the cache: raw gateway responses with tokens beyond their TTL, cart sessions with payment data, debug output. Check WooCommerce session keys before copying a cache dump to staging.
• debug.log. WP_DEBUG_LOG writing to wp-content/debug.log on a server with directory listing is a public log. Email addresses, tax IDs and addresses end up there as soon as a gateway throws an exception. Write logs outside the document root, rotate them, and limit access to operations staff.
• Full-page cache vs cart. Cache only catalogue and content pages. The cart cookie or session must trigger the bypass rule. A cached mini-cart showing another customer’s items is a confidentiality incident, not a performance win.

#Enterprise WordPress security services from WPPoland

WPPoland hardens WordPress and WooCommerce stacks against the standards corporate procurement actually checks: the hosting provider’s SOC 2 or ISO 27001 scope, NIS2 Article 21 measures, zero trust on wp-admin, plugin inventory and SBOM, checkout and gateway surface. WPPoland itself holds no SOC 2 report or ISO certificate; the evidence we deliver is operational.

1. Security in the code. Custom plugins and integrations reviewed against OWASP Top 10:2025, with ASVS 5.0 as the requirement list where the contract asks for one.
2. Monitoring plus review. Vulnerability and file integrity scanners run continuously. Human review covers gateway updates, role changes and restore tests.
3. Evidence. Patch SLA, restore record, subprocessor list and an incident runbook with the 24/72 hour path. Those are the deliverables in NIS2 and DORA questionnaires.

The starting point is a WordPress security audit. For regulated supply chains it pairs with an EU compliance audit for WordPress.

#How to keep a corporate CMS secure over time

A corporate CMS passes review in 2026 when the hosting evidence, the application model and day-to-day operations fit together. SOC 2 and ISO 27001 filter the provider. NIS2 Article 21 gives the list of measures and Article 23 the reporting clock. The Cyber Resilience Act puts reporting duties on plugin and theme vendors and gives buyers the right questions. OWASP Top 10:2025 and ASVS 5.0 turn “secure development” into testable requirements.

Security stays a cycle: inventory, harden, monitor, restore, prove. Without that cycle no certificate held by the host changes the outcome of the next incident. If the CMS is falling behind, document the current stack, access model, update process and recent incidents first. That makes a security review specific instead of generic.