Ransomware hits on a Friday evening. The team asks the host: who opened a session on our VPS in the last 48 hours? Answer: support tickets available, no SSH correlation, 7-day panel retention. The internal investigation stalls. The DPO waits for a timeline for regulator notification.
Administrator access is the most under-documented weak point in hosting. Encrypted production, firewall enabled — yet a shared root key, untraced support access, or wipeable logs can undo months of displayed compliance.
Two perimeters never to confuse
Host access (support, NOC, hypervisor). You do not control it directly. Require in the DPA: logging, notification for access without a ticket, log delivery deadline, no access without justification.
Customer access (SSH, app panel, CI/CD, admin DB). You are responsible. Named accounts, MFA, no shared root, API key rotation. Logs must leave the server to storage a compromised admin cannot erase.
| Source | Examples | Owner | Expected evidence |
|---|---|---|---|
| Host | Cloud console, rescue mode, hypervisor | Provider | Export within 72 h on request |
| Customer | SSH, sudo, deploy | You | SIEM or WORM bucket |
| Application | WordPress admin, back office | You + vendor | App logs + IP |
A credible audit trail links identity, action, timestamp, and incident ticket — not just "login successful."
Build a timeline that holds up to an auditor
Start by listing scenarios to reconstruct: suspected compromise, human error, support access during outage, overnight migration.
For each scenario, verify:
- Synchronized timestamps (NTP) on VMs and log services.
- Unique identity — not
admin@ordeployshared by ten people. - Immutability — logs copied off the compromisable server (Object Lock, remote syslog).
- Correlation — alert on admin access outside usual hours or without an associated ticket.
Ask the host for an anonymized support log sample showing format and retention. If the answer is "confidential," negotiate an audit clause or third-party report.
Mistakes that fail audits
Confusing web logs with admin logs. Apache access.log does not show who became root.
Retention too short at the host. You discover intrusion after 30 days; panel logs only go back 14.
Rescue mode without notification. The host mounts a disk in rescue to "help" — with no contractual trace or client alert.
Permanent break-glass account. The emergency account stays active all year instead of activate-use-disable-log.
Each point is fixed by a contract line and an annual test: simulate a log request for a fictitious incident.
The climax: without admin logs, no due diligence
Here is what availability SLAs do not mention.
The peak: require reconstruction capability, not a "enhanced security" promise. In a crisis, minutes matter — and deleted logs do not come back.
Decide and move forward without blind spots
Inventory every admin path: host panel, SSH, cloud API, database, CI. For each: who, where logs live, how long retained.
Add to the DPA: host log delivery deadline, format, escalation contact. On your side, ship logs to immutable storage this week — not after the incident.
Compare hosts on support transparency via our directory and compare tool. Link with Least privilege to shrink surface before logging.
Frequently asked questions
Must the host log its own admin access?
Yes for sensitive projects: hypervisor, panel, escalated support, and emergency access must be traced and contractually deliverable.
What minimum events on the customer side?
SSH/RDP, privilege elevation, IAM changes, admin DB access, deployments, secrets — with named identity.
How long to retain admin logs?
Depends on risk; often 6–12 months minimum. Align host and customer retention.
Are shared hosting panel logs enough?
Rarely for VPS or cloud. They may not cover SSH, API keys, or tier-3 hypervisor access.
In compliance, the question is not "do you have an admin?" — it is "can you prove what they did?"