Administrative access
Named accounts, SSH behavior, privilege, access lifecycle, and the handling of temporary credentials.
Case study · Linux server audit
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.
Published Last reviewed
Business question
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
Representative examples of how questionnaire items were translated into checks that could actually be performed and evidenced:
| The questionnaire asks | What was actually verified | Evidence 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
Named accounts, SSH behavior, privilege, access lifecycle, and the handling of temporary credentials.
Relevant Nginx or Apache, PHP, TLS, and service configuration within the authorized host.
File ownership, permissions, execution boundaries, and the potential impact between sites or processes.
Backup location, access, monitoring, and evidence that restoration could meet the business need.
Ownership
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
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