How an engagement works
Everything happens in writing, in your dashboard. There is no sales call. You read the findings before deciding on any fix, and nothing changes in production without a written scope, an agreed window and a way back.
The five stages
The dashboard shows each request’s current status, so you always know which stage it is in.
Request
Create an account, choose an assessment and describe the environment. No card is needed to create an account, and saving a request does not take payment.
- Company and the primary public website
- Hosting environment and the PHP version, if known
- How many servers and sites are in scope
- Urgency, known compatibility issues and the application journeys that matter most
- Confirmation that you are authorized to request an assessment of these environments
Dashboard status: Awaiting payment
Assessment
Once the assessment is paid and accepted, we work from the details you provided and the information we ask for in writing. If we cannot accept an assessment, it is refunded. Nothing in production is changed.
- Inventory every site, the runtime actually serving it, its worker pool and package source
- Correlate official PHP and distribution advisories, including backported fixes
- Record anything that cannot be confirmed as unknown, never as safe
Dashboard status: Queued, then Assessment in progress
Written findings
The report is published in your dashboard. It is written to be read by the person who owns the risk as well as the person who will make the change.
- A summary and the scope that was assessed
- A runtime inventory for every site
- Findings prioritized by severity, each with its evidence
- Remaining unknowns and what would resolve them
- A proposed remediation scope and a written quote, with the assessment fee credited once
Dashboard status: Quote ready
Remediation approval
You decide whether to go ahead. Approving the written scope and its price is a separate step and a separate payment. You can also take the findings to your own developer or hosting provider.
- The exact changes, sites and servers affected
- The price, with assessment credit applied
- Access arrangements and the maintenance window, agreed separately after approval
Dashboard status: Scheduled
Delivery and verification evidence
Changes are made only within the approved scope and the agreed window. Afterwards, we establish what is actually running, not only what was installed.
- Restart affected workers and confirm the runtime serving each site
- Run the agreed application checks and review error rates
- Record before and after evidence: package identity, authorization, checks run and result
- List anything unresolved, with an owner
Dashboard status: Remediation in progress, then Verification in progress, then Completed
Access and authorization
Never send credentials. Do not send passwords, private keys, access tokens or customer data through the dashboard, by message or by email. We will not ask for them there.
An assessment request confirms that you are authorized to have the environments assessed. It does not grant access to anything. Production access and production changes need a separate authorization.
Where a job needs access to your systems, it is agreed separately after we have reviewed the environment, limited to what the approved scope requires, and set up through a channel agreed for that purpose. Keys are never exchanged by email.
If you manage sites for clients, make sure you have their authority for the work before requesting it.
Maintenance windows and recovery
Production changes need three things in place first: a connected and authorized environment, an agreed maintenance window, and a recovery route that has been tested.
- Backups are checked for integrity before the change, not assumed.
- Updates are staged in a representative environment where possible, with your application checks run before production. Test runs avoid real payments and emails.
- Where several servers are involved, changes go to one recoverable server at a time, so a failure is contained.
- If a check fails, the agreed recovery procedure is followed.
A rollback can reintroduce the vulnerability that was being fixed. In that case the affected service is isolated and you are told, rather than vulnerable public exposure being quietly restored.
When work stops
These conditions pause the affected work and are escalated to you in writing.
- An operating system, package source, PHP branch or web server arrangement we have not qualified
- Patch or backport status that cannot be confirmed, or a package whose origin cannot be verified
- No tested backup and recovery route, or no meaningful application checks
- Version migrations, dependency replacements or database changes that were not approved
- Signs of compromise, integrity anomalies, or evidence that a routine change would destroy
- Unexpected behaviour in staging or production, a failed recovery or someone else changing the same system
A version comparison is not a security certification. A completed job means the approved change was deployed and the agreed checks passed, as recorded in the evidence.
Suspected compromise
Patching closes a vulnerability. It does not remove an attacker who has already used it, and a routine update can overwrite the evidence needed to understand what happened.
If there are signs that a system has been compromised, it is handled as incident response, not as an ordinary patch job. Routine work on the affected systems stops, relevant logs and evidence are preserved, and you are told what was seen.
Containment and investigation are not included in an assessment or in a standard remediation job. They need their own scope, which we will discuss with you or refer to an incident response specialist.
If you suspect a compromise now, preserve your logs before making changes and contact your hosting provider or an incident response specialist.
Automation
What exists today and what is being built.
Production patch execution is not automated today. Automated routine patching is in development, starting with supported PHP-FPM environments on Ubuntu and Debian. Until it is available, eligibility and delivery are reviewed individually, and every production change goes through the approvals described above.
The automated design keeps production changes in a narrow, deterministic controller that uses trusted package sources and runs only the change you approved. AI can help explain a plan or classify a failure. It cannot write shell commands, change the approved scope or override a recovery gate, and log output or web content is never treated as an instruction.
Start with an assessment
Questions about the process can be sent through the contact form. They are answered in writing.