Services
Two halves of the same job. Testing finds out what is actually true of your systems. Readiness work turns that into something a regulator, an auditor, an insurer or a customer will accept.
Security testing
Human-led testing, tool-assisted rather than tool-driven. You get findings rated by severity with reproduction steps, the business impact stated in plain terms, and remediation advice specific to your stack — not a scanner export with the vendor logo changed.
Web application penetration testing
Customer-facing products, internal portals, and the workflows the business actually runs on. Focus on authentication and session handling, authorization and privilege boundaries, business logic that can be driven somewhere it should not go, and input handling.
API penetration testing
REST and GraphQL. Broken object-level and function-level authorization, tenant isolation between customers, excessive data exposure in responses, and the endpoints that were never meant to be reachable from outside.
External attack surface assessment
What is reachable from the internet and should not be: forgotten hosts and subdomains, exposed management interfaces, DNS and TLS posture, and credentials or configuration leaking from places nobody is watching. Prioritized by what is genuinely exploitable. This is not an ASV scan and cannot serve as the PCI DSS quarterly external scan where your validation requires one.
Smart contract audit
Manual Solidity review: access control and privileged roles, economic correctness and rounding, reentrancy and external-call ordering, oracle and price-feed assumptions, upgrade and proxy patterns, and the failure modes that only appear under adversarial conditions rather than in the happy path. Delivered as a findings report with severity, impact and a concrete remediation for each item.
Method drawn from the OWASP Web Security Testing Guide, OWASP ASVS, the OWASP API Security Top 10, and PTES; smart contract work follows Solidity-specific threat modelling. Findings are mapped to CWE and rated with CVSS so they can be handed straight to your developers or your insurer. These are the standards the work follows — they are methodologies, not certifications, and I do not hold or claim accreditation in them.
See how a finding is written up — a worked exemplar against a deliberately vulnerable public application.
Who has to sign what
Several of these regimes reserve the final signature for someone holding a specific accreditation. That is worth knowing early, because it changes who you hire and in what order — and because readiness work done first makes their engagement shorter and cheaper. Where you need one of these, I will tell you which, help you choose, and give them a package that does not waste their time.
| Result | Only this party may issue it | What I do before they arrive |
|---|---|---|
| PCI DSS Report on Compliance or Attestation | A Qualified Security Assessor (QSA) | Scope and cardholder data flows, gap assessment, remediation, and the right self-assessment questionnaire where no QSA is required at all. |
| PCI DSS quarterly external scan | An Approved Scanning Vendor (ASV) | Scope it, read the results with you, and fix what it finds. |
| SOC 2 report | A licensed CPA firm | Control set, evidence collection, and the readiness assessment that decides whether Type I or Type II is the sensible first move. |
| ISO/IEC 27001 certificate | An accredited certification body | Statement of Applicability, risk treatment, internal audit and management review — the stage-one evidence. |
| HITRUST validated assessment | A HITRUST Authorized External Assessor; HITRUST issues the certification | The programme, the safeguards mapped to what runs, and the evidence set. |
| A legal opinion | Counsel | Tell you plainly when the question is legal rather than technical, and prepare the factual record counsel will need. |
Readiness is not a substitute for any of these, and a consultant who says otherwise is selling something they cannot deliver. It is what makes the signature achievable, and usually quicker.
Compliance and privacy readiness
Readiness means the controls exist, work, and can be evidenced — before someone external comes to check. Where a formal certificate or report is the goal, I prepare you for the firm that issues it and work alongside them. I do not issue it myself, and the limits below are stated on purpose.
The Evidence Pack
Two weeks, fixed scope. The questionnaire or insurance application on your desk, answered honestly with a written record behind every answer. The usual way in.
PCI DSS 4.x readiness
Scope definition and cardholder data flow mapping, gap assessment against the current requirements, remediation plan, and support completing the right self-assessment questionnaire.
HIPAA and HITRUST readiness
Safeguards mapped to what you actually run, policy and procedure set, workforce training, risk analysis, and breach procedure. I have run this programme once, for a NYSE-listed organization.
SOC 2 readiness
Control design against the trust services criteria you are actually claiming, the evidence architecture to sustain them, a gap assessment before you spend audit money, and liaison with your auditor during fieldwork.
ISO/IEC 27001 readiness
ISMS scoping, risk methodology, Statement of Applicability, the documentation set, and an internal review before the certification body arrives.
Pre-examination review
The examination before the examination. Somebody external is coming — an auditor, an assessor, a customer’s security team, a supervisor — and the question is whether you would pass today. This is that assessment, run against the same standard they will use and in the same order they will use it: scope first, then whether each control exists, then whether it operates, then whether you can evidence that it operates without three days of scrambling.
What comes back is a finding list in the shape their report will take, sorted by what would actually be raised, with the cheap fixes separated from the ones that need a decision and a budget. The point is that nothing in their report is the first time you heard about it.
Operational resilience, continuity and recovery
What happens when it stops. Business impact analysis that names the processes you cannot lose and for how long, recovery objectives that someone has actually agreed rather than inherited, dependency mapping through your suppliers, and a continuity and disaster recovery plan written to be executed by whoever is on shift — not to sit in a binder. Then the part most plans skip: testing that the restore works and that the backups are reachable when the thing that broke is the thing holding the backups.
Incident response readiness and tabletop exercises
Before an incident, not during one. An incident response plan with named roles and real decision points, the notification questions answered in advance — which regulator, which clock, which threshold — and a facilitated tabletop that puts your people through a scenario built from your own architecture rather than a generic template. The output is a written record of what worked, what stalled, and who needs authority they do not currently have.
Third-party and vendor risk
The other side of the questionnaire. Assessing the suppliers you depend on: what data they hold, what access they have, what their SOC 2 or ISO certificate actually covers against what you assumed it covered, and where a subprocessor moves your data somewhere your own commitments do not allow. Includes the tiering and reassessment cadence, so the programme still works in a year without a consultant running it.
Technology risk assessment, controls and policy
Risk assessment and threat modelling against the systems as built, a control set designed to the risks rather than copied from a framework, and the policy and standards written to match what the controls actually do. Where a control exists on paper and not in the estate, that is what the assessment says. Also the reverse, which is more common: a control that is genuinely enforced and that nobody has written down, so it earns no credit in an audit or a questionnaire.
AI and LLM governance
You put a model in the product, or your staff started pasting client material into one, and now a customer’s security questionnaire has a section about it that nobody can answer. The work: what the system actually sends to which provider and under what terms, where the prompts and outputs are retained, whether personal information is leaving a jurisdiction it should not, human oversight where a decision affects someone, and the controls that answer the OWASP Top 10 for LLM applications — prompt injection, insecure output handling, excessive agency, data leakage through the model. Mapped against the EU AI Act where it reaches you, ISO/IEC 42001 and the NIST AI Risk Management Framework where a customer asks for a named standard. The scope is the system around the model — what it sends, what it retains, who reviews the output — which is the part a questionnaire actually asks about.
Limit: this is governance and security assessment of systems that use models. It is not model evaluation, red-teaming for alignment, or a statement about how well a model performs — those are a different discipline and I do not claim them. I am also not an accredited ISO/IEC 42001 certification body.
Privacy programme
PIPEDA and BC PIPA, plus GDPR or Quebec Law 25 where they reach you. Data inventory and flows, retention and disposal, consent and notice, breach assessment procedure and register, vendor and cross-border transfer questions, and privacy impact assessments.
How engagements are priced
Testing is quoted in writing once scope, architecture, access level, target count and timing are understood — there is no useful day rate for work whose size is unknown. Readiness engagements with a defined deliverable are quoted as a fixed fee before work starts.