A safe, structured checklist for agencies preparing access for an inherited PHP/Linux system audit. The aim is enough context without unnecessary production risk, excessive permissions, or insecure credential sharing.
Please do not paste code, credentials, API keys, customer data, database dumps, private logs, or screenshots containing sensitive data into the contact form or ordinary email.
| Area | Minimum useful access | Notes |
|---|---|---|
| Business context | Short explanation of what the system does | Helps separate critical business logic from low-value technical noise. |
| Application/CMS | Admin access or guided walkthrough | Read-only or restricted admin preferred where available. |
| Codebase | Repository read access, zip snapshot, or hosted file-tree review | Repository access is best because history and dependencies are visible. |
| Hosting/server | Hosting dashboard, server notes, or read-only SSH | Root/sudo is not needed for the first pass unless explicitly scoped. |
| Database | Engine/version details and schema visibility | Full database dumps are usually unnecessary for an audit. |
| Backups | Backup location, retention, schedule, ownership, and last restore test | We need to know whether restore is realistic, not just whether backups exist. |
| Deployment | Notes on how changes currently go live | Manual FTP, SSH deploys, CI/CD, plugin updates, and rollback steps all matter. |
| Contacts | Technical owner, agency lead, client approver | Critical for assumptions, approvals, and incident escalation. |
Useful questions: What happens if this system is down for one day? Who currently fixes production issues? What change is the client asking for now? What are you afraid might break?
For WordPress, WooCommerce, Laravel, custom PHP, Symfony, CodeIgniter, or similar systems, temporary named users and repository read access are preferred.
Provider, server type, OS version, web server, PHP runtime, database version, control panel, SSL, DNS, CDN/WAF, backup provider, and monitoring provider.
Read-only or restricted user preferred for audits. Sudo/root only when explicitly scoped and approved. Key-based SSH preferred over password login.
Schema visibility and engine/version details are usually enough. Full production database dumps are usually unnecessary for an audit.
Gather location, owner, frequency, retention, encryption, off-server status, last successful backup, last restore test, restore procedure, and expected restore time.
The audit flags deployment risks and recommends safer next steps where appropriate.
| Engagement | Preferred access level | Production changes? |
|---|---|---|
| Audit | Read-only wherever possible | No, unless separately scoped |
| Handover | Read-only plus stakeholder walkthroughs | Usually no |
| Sprint | Limited write access for agreed fixes | Yes, with written approval |
| Upgrade | Staging and deployment access | Yes, with backup and rollback plan |
| Care | Ongoing least-privilege access | Only within agreed monthly scope |
| Rescue | Case-specific emergency access | Only with explicit approval and rollback thinking where possible |
Do not send passwords, SSH private keys, API keys, .env files, payment gateway credentials, database dumps, production logs, customer exports, screenshots containing personal data, code snippets containing secrets, or confidential documents before NDA if one is required.
Start with the business context and the current worry. StackRefit will confirm the minimum access needed after scoping.