An auditor's findings report arrives and one line changes the quarter. The organization needs immutable audit logs showing who changed which piece of content and when. Or field-level permissions separating who can see customer data from who can edit the page it sits on. Or authentication that defers to the corporate identity provider rather than maintaining its own user table.
The content management system (CMS) running the website was never designed to answer questions like these. It was designed to publish pages. What follows is a scramble to translate audit language into technical work, usually against a re-audit date somebody else set, with the answer landing somewhere between a configuration change and a full rebuild.
Audit Findings Are Where Platform Limitations Finally Become Visible
A CMS gets selected on editorial experience, template flexibility, and cost. Nobody evaluates it against a control framework, because at selection time there is no framework in the room. The platform performs exactly as promised for years, and the gap stays theoretical.
An audit converts that gap into a documented deficiency with a due date. The finding is rarely that the platform is insecure. It is that the platform cannot produce evidence, cannot enforce a distinction the organization claims to enforce, or cannot restrict something at the level the control requires. Those are architectural limits rather than misconfigurations, which is why hardening and patching do not close them.
This is also the moment the platform stops being a marketing asset and becomes part of the organization's control environment. That reclassification drives the rethink, and it happens whether or not anyone planned for it.
What Do Security Audits Typically Find in a Web Platform?
Findings against a content platform cluster into a predictable set, because the frameworks test the same underlying capabilities regardless of which standard applies. Five appear most often:
Audit logging that is incomplete, inconsistently formatted across modules, or impossible to query for who changed what and when.
Role definitions too coarse to enforce least privilege, particularly where one permission bundles content editing with access to user or customer data.
Authentication handled inside the platform rather than delegated to the corporate identity provider, leaving provisioning and deprovisioning outside the organization's access reviews.
Data handling and retention that cannot be enforced at the field level, so information the organization committed to deleting persists in form submissions, revisions, or media libraries.
Change management evidence that cannot be reconstructed, since content and configuration changes leave no reviewable approval trail.
Third-party module risk sits underneath all five. Practitioners report that companies selecting WordPress for regulated platforms typically hit two problems within 18 months, plugin security debt and audit trails too shallow for compliance review. The pattern is not platform-specific. Any capability delivered by a third-party extension is a capability the organization does not fully control.
Off-the-Shelf Platforms Were Built for Publishing, Not for Producing Evidence
The gap is a design consequence rather than a defect. A CMS optimizes for letting non-technical people publish quickly, and every governance surface that slows publishing is a secondary concern. Practitioners in enterprise content governance describe the log as the most boring control in the program until the moment it is the only thing that matters, and note that most platforms treat it as an afterthought that is bolted on, partial, and hard to query.
Permissions follow the same logic. Widely used platforms handle role-based access adequately and attribute-based access poorly, so an organization with a complex permission matrix needs custom development or an identity layer in front of the platform. Neither is a setting.
Recognizing this early matters, because it determines whether remediation is a configuration conversation or a development one. Marcel Digital works through that distinction before scoping any application modernization effort, since a finding requiring new capability and one requiring better configuration have almost nothing in common in cost or timeline.
Every Finding Resolves Into One of Four Responses
Sorting findings by response type is the fastest way to turn a report into a plan, and it prevents the common failure of treating every finding as equally urgent or equally expensive. Four options exist:
Configure: The capability exists but is switched off or set incorrectly. Cheapest and fastest, and worth ruling out first on every finding.
Extend: A supported module or first-party feature delivers the capability. Reasonable, provided someone owns the maintenance and the extension sits inside the platform's supported surface rather than being an unmaintained community add-on.
Build Custom: The capability does not exist and cannot be bolted on reliably. This is where custom web applications, API development to delegate identity or logging to a system built for it, and platform integration work belong.
Replatform: The architecture cannot support the control environment at all, and a website migration to a platform like Umbraco or a headless CMS is the honest answer.
Replatforming under a compressed re-audit deadline is almost always the wrong sequence, even when it is the right destination. A migration introduces risk across content, integrations, and SEO at the moment the organization can least afford an incident, and it will not finish in the window. Close what can be closed, document time-bound compensating controls for what cannot, and put the migration on a real timeline with the audit finding as its business case. Auditors accept a documented remediation plan with owners and milestones. They do not accept a platform decision made in a panic.
Which Security Standards Actually Apply to Your Situation?
Which standards apply depends on industry, contracts, customer requirements, and geography, which is why architecting to one specific mandate is a mistake. Build the capabilities the frameworks test instead, since those overlap heavily. Practitioners who implement both note that organizations with ISO 27001 Annex A controls in place typically find 60% to 80% of SOC 2's Trust Services Criteria already addressed.
Four capabilities carry most of that weight. Verifiable identity and access management, authorization granular enough to enforce whatever separation the organization claims, tamper-resistant logging with defined retention, and field-level data handling controls. A platform that does those four things well can satisfy an ISO 27001 audit, a SOC 2 examination, a customer security questionnaire, or a privacy review without being rearchitected for each.
Determining which frameworks bind a specific organization is work for compliance counsel and the audit firm, not a development partner. The architectural question is separable, and treating it that way keeps remediation moving while scope gets settled.
Remediation Stalls When Compliance, IT, and Marketing Each Own Part of the Problem
Three groups touch a CMS finding and none owns all of it. Compliance owns the finding and the deadline but cannot evaluate technical options. IT owns the platform but never agreed to the deadline and has a committed roadmap. Marketing owns the site, the content operations the fix will disrupt, and often the budget it will consume.
Guidance on compliance remediation consistently names fragmented ownership and legacy platform constraints as primary causes of findings going stale, and recommends one accountable owner per finding supported by a documented responsibility map across security, IT, and the business. That means one person owning each finding end to end, with authority to approve a technical approach and standing to negotiate the timeline.
The practical test is whether someone can say, for any given finding, what the chosen response is, who is building it, when it will be verified, and what control holds until then. When no one can answer that, the finding is not being worked. It is being discussed.
Marcel Digital Helps Teams Close Audit Findings Without Rebuilding Everything
Marcel Digital works with organizations facing audit-driven platform requirements, translating findings into technical scope, separating what configuration can close from what requires development, and delivering remediation against the re-audit date without forcing a premature replatform.
The team supports platform assessment, custom development, identity and logging work, and website hosting and maintenance for organizations whose web platforms have become part of their control environment. For teams already committed to a full roadmap, enterprise development support adds capacity for audit work without displacing planned initiatives.
If an audit has produced findings your current platform cannot close, connect with Marcel Digital to scope a remediation path that satisfies the auditor and leaves you with architecture worth keeping.
Frequently Asked Questions
Findings cluster around audit logging depth, role granularity, authentication handled inside the platform instead of through the corporate identity provider, field-level data handling and retention, and the absence of a reviewable approval trail for content and configuration changes. Third-party module dependencies underlie many of them.
Usually not. Most findings close through configuration or a supported extension, and a smaller set requires custom development or an integration that delegates identity or logging to a system built for it. Replatforming is the correct answer only when the architecture cannot support the control environment at all.
Document a time-bound compensating control alongside a remediation plan with named owners and milestones. Auditors work with documented plans routinely. What they do not accept is a finding with no owner, no interim control, and no date.
Build to capabilities rather than to a single standard, because the frameworks test substantially the same things. Verifiable identity and access management, granular authorization, tamper-resistant logging with defined retention, and field-level data handling will serve an ISO 27001 audit, a SOC 2 examination, or a customer security review. Which frameworks legally bind your organization is a question for compliance counsel and your audit firm.
One accountable person per finding, with authority to approve a technical approach and standing to negotiate the timeline. Compliance, IT, and marketing each hold part of the problem, and splitting ownership across all three is a reliable way to let findings go stale.
Configuration changes can close in days. Custom development typically runs weeks depending on scope and verification requirements. A replatform runs months, which is why it rarely fits inside a re-audit window and is better scoped as a separate initiative using the audit finding as its business case.
