Security Audit & Remediation for a Membership Society

A useful audit starts with an agreed scope. Together with the society we listed every component that touched member data: the portal application, the WordPress site in front of it, the payment integration and the two servers they ran on. Testing took place against a staging copy, while live-server configuration was reviewed read-only, so members were never affected.

Working from a staging copy also meant we could explore more thoroughly. Findings that would have been risky to confirm on a live system could be demonstrated safely, which made the eventual report far more convincing to both the trustees and the insurer.

• Application, CMS, payment integration and servers all in scope
• Testing on staging; production configuration reviewed read-only
• Methodology aligned with the OWASP Top 10

The audit identified nineteen issues. The most serious was an access-control flaw: a logged-in member could view another member’s profile by changing an identifier in the address bar. Because the portal held personal details for every member, this was the first priority for remediation.

Other findings were typical of a platform that had grown over time — an out-of-date payment plugin, password-based SSH access to the servers, missing security headers and a range of smaller configuration weaknesses. None of them was exotic, but together they described a portal that needed attention across every layer.

We fixed the application issues directly, adding ownership checks so members can only ever reach their own records. The vulnerable payment plugin was updated and placed behind a web application firewall, and both servers moved to key-only SSH with a hardened Nginx configuration, current TLS settings and security headers.

Every fix was then re-tested. Closing a finding meant demonstrating that the original issue could no longer be reproduced, not simply that a change had been deployed. All nineteen findings, including the three critical ones, were closed and re-tested within three weeks.

• Ownership checks on every member record
• Plugin updated and protected by a WAF
• Key-only SSH, hardened Nginx, modern TLS and headers

A security report has to work for people with very different needs. Trustees and the insurer needed to understand the overall risk, what had been fixed and what remained, without wading through technical detail. Developers needed exact reproduction steps, affected components and the evidence behind each finding.

We wrote both: an executive summary in plain English and a technical appendix organised by finding. The insurer accepted the report, the renewal completed at the standard premium, and the society now runs a quarterly re-audit so new plugins and code changes are checked before they become the next finding.