What an Engagement Looks Like
Three engagement models, because testing a product, assessing a program, and building a control are genuinely different jobs. The scoping, paperwork, and setup are the same for all three.
Start a ConversationScoping, Paperwork, and Setup
The first conversation is short and free. From there, the formal pieces are designed to move quickly so we can get to the actual work.
-
Scoping call
A 30 to 45 minute conversation to understand the system or the organization, the question you are trying to answer, and the constraints of timeline, budget, and obligation. No NDA required, because we keep this conversation high-level.
-
NDA, then technical scoping
Mutual NDA in place before we look at architecture diagrams, code, pipelines, or sensitive context. We work from your NDA or ours, whichever moves faster.
-
Statement of Work or MSA
A short SOW for one-off engagements, or a master agreement plus per-engagement SOWs for ongoing relationships. Scope, deliverables, timeline, and pricing are written down before we start.
-
Kickoff
Access provisioning, communication channels, and the engagement plan. We confirm what is in scope, what is out, and who the point of contact is on each side.
Working With Procurement
Larger organizations run a vendor assessment before any work starts. That process is usually the slowest part of an engagement, so here is exactly what it involves on our side.
What we sign
- Mutual NDA before any architecture, code, or sensitive context changes hands. Your paper or ours, whichever moves faster.
- SOW or MSA. A short statement of work for one-off engagements, or a master agreement with per-engagement SOWs for ongoing relationships.
- Additional terms for restricted information. Where an engagement involves protected health information, cardholder data, confidential audit evidence, export-controlled technical data, or other contractually or legally restricted material, those terms are negotiated before access is granted, not after.
How engagement data is handled
- Mutual non-disclosure with no expiration on confidentiality of sensitive material
- Encrypted transport for everything sensitive
- Storage limited to the engagement team, with multi-factor authentication and least privilege
- A documented handling and access trail for findings, reports, and supporting artifacts
- Return or secure destruction of engagement data at closure
Send us your requirements
- Your security questionnaire or vendor risk assessment, and we will complete it
- Your onboarding checklist, insurance requirements, and supplier code of conduct
- Any procurement portal we need to register in
- The named contacts on your side for legal, security, and procurement
What speeds this up
- Sending the questionnaire during scoping rather than after the SOW is drafted
- Telling us early if the engagement touches regulated data
- Naming one person who can resolve access and approval questions
- Flagging any deadline the work is tied to, such as a customer review or an attestation date
The full detail on how engagement data is stored, retained, and destroyed is in our privacy policy.
Which One Applies
Most clients recognize their situation in one of these. Engagements that span two practices run both models in sequence, and we say so during scoping rather than stretching one shape to cover everything.
Security Testing: Scope, Test, Report, Re-test
Used for penetration testing, application security assessments, AI security testing, and technical security assessments.
A point-in-time question about a specific system: is this secure enough for what it does, and what would an attacker reach?
What we do
- Architecture and threat surface walkthrough
- Read prior reports, design docs, and known issues
- Confirm boundaries: in scope, out of scope, and explicitly off limits
- Calibrate the threat model to your business context
What we need from you
- Access to the system, code, or environment
- 30 to 60 minutes from a technical lead
- Any prior security work we should build on
What we do
- Threat modeling against the agreed model
- Manual review of the code and architecture that matters
- Hands-on testing: injection, abuse, escalation, and chaining
- Weekly status and a live findings tracker
What we need from you
- A point of contact for technical questions
- Test environment access where applicable
- Quick acknowledgement of anything critical we surface mid-engagement
What we do
- Executive summary stating risk in business language
- Findings with severity, impact, and reproduction steps
- Attack narrative showing how findings chain together
- Remediation plan ordered by risk reduction per unit of effort
How we deliver it
- Draft shared for technical accuracy review before it is final
- Walkthrough call with engineering and leadership
- Final PDF, plus a redacted version for customers or the board if useful
What we do
- Re-verify each remediated finding against the original test
- Check whether the fix introduced new exposure
- Document accepted or deferred risk in writing, with the owner named
What you will see
- Re-test summary: closed, open, or accepted
- Updated report appendix you can hand to auditors or customers
- A documented closure record
Software Security Assurance: Discover, Evaluate, Roadmap, Validate
Used for program assessments, evidence readiness, secure SDLC assessments, regulatory readiness, and customer assurance readiness.
A question about the organization rather than a single system: does the program work, consistently, and can you show it?
What we do
- Review policies, standards, and prior assessment work
- Map teams, repositories, pipelines, and release paths
- Identify the stated owner for each area in scope
- Agree the sample of services and releases to examine in depth
What we need from you
- Read access to documentation, pipelines, and finding queues
- Introductions to the engineering and security leads
- The requirement or deadline driving the work, if there is one
What we do
- Structured interviews with the people who do the work
- Direct examination of pipelines, tool configuration, and queues
- Trace sample vulnerabilities from discovery through to closure
- Trace sample releases through the gates that should have applied
- Separate control gaps from evidence gaps
What we need from you
- About an hour per interview
- Read access to a representative sample of build and release records
- A contact who can unblock access quickly
What we do
- Map findings to the public frameworks relevant to your obligations
- Prioritize by risk reduction per unit of effort
- Sequence twelve months of work with dependencies made explicit
- Draft the narrative for the audience that has to approve it
What you will see
- Draft report circulated for factual accuracy first
- A working session on prioritization against your real constraints
- Executive presentation delivered live
What we do
- Re-examine the areas addressed since the assessment
- Sample releases and findings again to test consistency
- Attempt the bypass paths where a gate is meant to block
- Record residual and accepted risk in writing
What you will see
- Validation report stating, per area, whether the control operates
- Updated evidence inventory reflecting current state
- A clear statement of what remains open and who accepted it
Security Engineering: Design, Build, Operationalize, Measure
Used for DevSecOps, security automation, architecture, remediation, security integrations, and control implementation.
A build engagement. The question has already been answered; now something has to be written, deployed, and handed over.
What we do
- Review the finding, roadmap item, or requirement driving the work
- Assess the existing stack and the constraints it imposes
- Choose the approach and write down what was rejected and why
- Define the measure that will show the control is working
What we need from you
- Repository and pipeline access
- Time from an engineer who owns the affected system
- Agreement on the success measure before the build starts
What we do
- Write the control, the automation, or the fix
- Cover it with tests so a later change that breaks it fails loudly
- Ship in reviewable increments rather than one large drop
- Raise anything that turns out to be harder than scoped, early
What we need from you
- Code review from your team, at your normal cadence
- A staging or test environment where applicable
- Fast decisions when a trade-off needs your call
What we do
- Documentation and runbooks written for the inheriting team
- Ownership, alerting, and escalation paths agreed and recorded
- Rollout sequenced across teams, with the noise tuned down first
- Handover session with the engineers who will own it
What you will see
- A named owner for the control on your side
- Runbooks covering the failure modes, not just the happy path
- A tuning period before the control starts blocking anything
What we do
- Report against the success measure defined in phase one
- Test the bypass paths where the control is meant to block
- Identify what the control does not cover, in writing
- Recommend the next increment if one is worth doing
What you will see
- Evidence the control is operating, suitable for an assurance evidence set
- An honest statement of residual coverage gaps
- A closing recommendation, including when the answer is to stop here
What Comes Next
Some engagements end at the final report. Others become long-term relationships. Both work for us, and we do not pressure either direction.
-
Standalone engagement
A point-in-time assessment: scope it, run it, deliver it, close it. Useful when you have a specific question or an obligation with a date attached.
-
Quarterly cadence
For teams shipping fast, a recurring engagement keeps the threat model and the evidence current, and catches drift before it compounds.
-
Retainer or embedded
For organizations that want senior product security judgment continuously available without a full-time hire. Reserved hours, agreed response times, direct access.
-
Assess and build
When remediation needs more than a recommendation, the same people who found the gap can build the control, under a separate SOW.
Ready to scope something?
Tell us what you are working on. The first conversation is short, free, and useful either way.
Start a Conversation