Every engagement follows the same sequence: agree the scope in writing, define what we may touch and when, gather evidence, rate risk by business impact, report with enough detail to act on, and re-test after remediation. This page documents that method so you can hold us to it and compare it with anyone else you are considering.
Scope Before Work
No billable work begins without a written scope and estimate. The scope names the systems, locations, accounts, and data in scope, lists what is explicitly out of scope, and states the deliverables. If the work changes, the scope changes in writing first. This protects you from an open-ended invoice and protects us from being asked to assess something we were never authorized to touch.
Rules of Engagement
Testing and assessment work is authorized in writing by someone entitled to authorize it. The rules of engagement cover the testing window, source addresses, accounts we may use, systems we may not touch, the escalation contact who can stop the work at any moment, and what happens if we find an active compromise during the engagement. For production environments we agree a maintenance window and a rollback plan before any intrusive test.
Assessment Method
- Discovery: inventory what exists and who owns it, from documentation and from the systems themselves. Discrepancies between the two are findings.
- Configuration review: examine the settings that actually determine exposure: authentication, patching, remote access, logging, backup, and permissions.
- Validation: confirm the suspected weakness rather than reporting a scan result. A finding without evidence is a rumor.
- Impact analysis: what an attacker could reach from this position, and what it would cost the business.
- Reporting: findings, ranked, with the evidence and the fix.
Details of what an assessment covers are on the cybersecurity assessment page.
Incident Response Method
- Triage: establish what is happening, what is affected, and who needs to be called. Containment actions are chosen to preserve evidence.
- Preservation: memory, disk images, logs, and mail are collected and hashed before anything is rebuilt.
- Scoping: determine the entry point, the dwell time, the accounts and systems touched, and what left the network.
- Eradication and recovery: remove the foothold, close the entry point, restore from verified backups, and rotate credentials.
- Reporting: a written account of what happened, in language counsel and the insurer can use.
Process detail on the incident response page; what to do in the first hours is in the first 72 hours.
AI Security Testing Method
AI systems fail differently from web applications, so they are tested differently. We start from the application’s actual permissions: what the model can read, what tools it can call, and whose authority it acts with.
- Prompt injection, direct and indirect: instructions typed by a user, and instructions hidden in documents, emails, or web pages the system reads.
- Guardrail evasion: attempts to bypass the stated policy of the application.
- Data leakage: whether the system can be induced to reveal other users’ data, system prompts, or material outside the caller’s permissions.
- Authorization boundaries: whether the assistant respects the access controls of the underlying systems.
- Robustness: behavior under malformed, adversarial, and out-of-distribution input.
Scope and deliverables are described on the AI security assessment page. The failure modes are explained in prompt injection.
Evidence Handling
Digital evidence is only useful if it survives scrutiny. Collected items are hashed at the time of collection, stored with restricted access, and recorded in a chain-of-custody log that names who handled each item and when. Nothing is analyzed on the original media. Where an incident may end in litigation, an employment action, or an insurance dispute, counsel directs the investigation so the work can be protected by privilege.
Risk Rating
We rate risk as likelihood multiplied by business impact, not by scanner severity alone. A critical CVSS score on a system with no data and no reachable path is not the same as a medium finding on the server that holds your client records. Each rated finding states the affected asset, the plausible attack path, the business consequence, and the effort to fix it.
Reporting Standard
Every finding in a report includes six things: the evidence we observed, the impact if it is exploited, the affected asset or account, the specific remediation, the owner who should perform it, and a priority. Reports are written for two readers at once, the engineer who will fix the issue and the executive who has to fund it, with a one-page summary first.
Peer Review and Re-Test
Findings are reviewed by a second engineer before delivery. After remediation, we re-test the same items and record the result, because a fix that has not been verified is a claim. Where a client wants it, the re-test is a separate, short engagement with its own written result.
What We Don’t Do
- We are not a certification body. ISO 27001 certification audits are performed by accredited registrars, and PCI DSS on-site assessments may require a Qualified Security Assessor.
- We do not provide legal advice. Notification duties, contract interpretation, and regulatory positions belong with your counsel.
- We do not guarantee that a system cannot be breached. We can tell you what we found, how we found it, and what remains untested.
- We do not run intrusive tests without written authorization and an agreed window.
Our standards and frameworks page explains which frameworks we map findings to and where our role stops. How engagements are priced and run is on how we work, and the results are in the case studies.
Schedule a free consultation or call 703-486-0200.