Case study · Linux server audit

Case study: turning a cyber-insurance questionnaire into verified server controls.

A membership-site operator received a cyber-insurance questionnaire full of questions the business could not answer with evidence: MFA coverage, patching cadence, backup restoration, access control, logging. Rather than guessing “yes”, the operator commissioned a server security audit so every answer could point to a verified control — and every gap became scheduled engineering work instead of a hidden liability.

Environment
WordPress membership site on a Linux web server
Driver
A cyber-insurance questionnaire requiring evidence-backed answers
Focus
Host access, SSH, PHP isolation, backups, and restoration
Result
Answers mapped to verified controls; gaps remediated and retested

Business question

Why guessing “yes” on an insurer questionnaire is the expensive option

Cyber-insurance questionnaires blend application, server, access, backup, and operational questions into one document — and they are answered under a duty of accuracy. An optimistic answer that later proves wrong is worse than a documented gap: misrepresented controls are a classic reason insurers dispute claims after an incident, precisely when the business most needs the cover to hold.

The operator ran a membership site — recurring revenue, member personal data, and a login-protected application — on a Linux server the business controlled but had never independently reviewed. Most questionnaire items concerned that layer beneath WordPress, where assumptions had quietly accumulated for years.

The engagement therefore had a precise goal: for each relevant question, either verify the control and record the evidence, or record the gap honestly and turn it into assigned work. Nothing would be answered from memory.

The mapping

From questionnaire language to observable controls

Representative examples of how questionnaire items were translated into checks that could actually be performed and evidenced:

The questionnaire asksWhat was actually verifiedEvidence recorded
Is multi-factor authentication enforced for administrative access?MFA state on the hosting panel, SSH key policy, and WordPress administrator accounts — coverage checked per account, not assumed from a policy.Account-by-account review with configuration extracts.
Are systems patched and supported?Operating system and package support status, pending security updates, PHP version lifecycle, and the update workflow actually in use.Version and repository inventory with support-window notes.
Is access to systems restricted and controlled?Named accounts versus shared logins, privilege levels, SSH exposure and configuration, and the lifecycle of temporary access.Account inventory, SSH configuration review, and access-path map.
Are backups maintained and tested?Backup destination and separation from the server, schedule and monitoring — and whether a restoration had ever actually been performed.Backup configuration review and a restoration test with its result.
Is activity logged and retained?Which authentication, web, and administrative events were logged, where logs lived, and how long they survived — including whether an attacker could erase them.Log source inventory with retention and access notes.
Are environments segregated?PHP process isolation, file ownership and permission boundaries, and what a compromise of one component could reach.Isolation review with the practical blast-radius assessment.

Assessment

The review followed the control boundary beneath WordPress

Administrative access

Named accounts, SSH behavior, privilege, access lifecycle, and the handling of temporary credentials.

Web stack

Relevant Nginx or Apache, PHP, TLS, and service configuration within the authorized host.

Isolation

File ownership, permissions, execution boundaries, and the potential impact between sites or processes.

Recovery

Backup location, access, monitoring, and evidence that restoration could meet the business need.

Ownership

Separating client-owned controls from provider-owned ones

Several questionnaire items concerned controls the hosting provider owned — physical security, hypervisor isolation, parts of the network boundary. Those were explicitly marked as provider-dependent rather than silently answered on the provider’s behalf, and the provider’s published assurances were referenced where they existed.

That separation matters in both directions: the operator could answer confidently about controls actually within reach, and the insurer received an honest boundary instead of an answer nobody could stand behind. Unknowns were recorded as unknowns — a recorded exception is defensible; a guessed “yes” is not.

Remediation and retest

Observed gaps became assigned engineering work

The report separated urgent exposure from planned hardening and provider dependencies, and named an owner for each item. The responsible team implemented the agreed changes, after which the affected controls were retested and their status updated in the report — so the questionnaire answers referenced verified end-states, not intentions.

The final output supported the questionnaire response with evidence behind each answer, while stating its own limits: a point-in-time audit does not guarantee future security, and it covers the agreed scope rather than every clause an insurer might raise.

Lessons

Evidence makes third-party assurance defensible

  • Answer questionnaires from verified controls, not from memory — misrepresentation risks the cover itself.
  • Map every questionnaire item to something observable, an owner, and a piece of recorded evidence.
  • Distinguish application controls from server controls from provider controls, and say which is which.
  • Treat backup success and restoration readiness as different questions — only a performed restore answers the second.
  • Record exceptions and unknowns instead of hiding uncertainty; insurers respond better to a plan than to a surprise.
  • Retest the controls that changed before presenting them as resolved.