Approach

Engagements run against a consistent operating spine regardless of whether the work is a penetration test, a social engineering assessment, a compliance audit, a hygiene assessment, or a strategic advisory engagement. The shape does not change: pre-engagement scoping, intelligence gathering and threat modeling, execution, reporting, and debrief. What changes is the methodology applied at each phase. Technical engagements run against the Penetration Testing Execution Standard. Compliance engagements run against the framework the organization is preparing for. The operating discipline that wraps every engagement, fixed-scope and fixed-fee and time-boxed with written commitments before active work begins, also does not change. This page covers the engagement lifecycle in operational detail. Each service page covers the methodology specifics for the engagement type in question.

Engagement lifecycle

Pre-engagement. Pre-engagement is where the engagement gets defined before any active work begins. Scope is agreed in writing, including what is in bounds and what is not. Rules of engagement specify any production-impact thresholds the client wants observed, the data-handling expectations, and the escalation contacts on both sides. The timeline is committed: start date, milestone checkpoints, and delivery date. Where the engagement involves credentialed access, the credential exchange and handling protocol is specified before credentials are provisioned. This phase produces the engagement charter that every subsequent phase references.

Intelligence gathering and threat modeling. These phases are concrete deliverables, not procedural decoration. For technical engagements, public-source reconnaissance produces the picture an external adversary would build before targeting the organization, and the threat model is anchored to the organization’s actual risk surface (industry, regulatory exposure, known threat profile, public footprint) rather than to a generic enterprise template. For compliance engagements, this phase maps the framework’s control requirements against the organization’s documented controls, producing the gap inventory that informs the operational assessment phase. For strategic advisory work, this phase produces the objective definition and scenario design that the active engagement runs against.

Execution. Execution varies by engagement type. The shared principle across types is that automated tooling output (scanner findings, configuration-baseline reports, awareness-platform metrics) is the starting point for analysis, not the conclusion. Every finding is validated manually against the actual environment, and where exploitability or operational impact matters, that exploitability or impact is demonstrated rather than asserted. Where the engagement is constrained by rules of engagement (production-system carve-outs, sensitive-data handling restrictions, brittle legacy infrastructure), the engagement documents what was tested, what was not tested and why, and what the constraint means for the confidence on each finding.

Reporting and debrief. Reporting delivers an executive summary in business language readable by a non-technical board member, a technical findings section at the depth a defender needs to act, remediation guidance that a sysadmin or compliance owner can execute without the tester present, and where engagement-type appropriate, a findings matrix the client can use to track remediation through closure. The debrief is a working call, not a deliverable handoff: findings are walked, prioritization is confirmed against the client’s actual operating capacity, and the remediation path is left in shape to be executed. A letter of attestation confirming engagement completion is available on request, appropriate for auditor or regulator interest. Findings frequently surface specific needs that justify a follow-on engagement, and the debrief is the right place to surface that without the report reading as a sales pitch.

Operating discipline

Engagements are scoped fixed-fee and committed in writing before active work begins. The fee is set at engagement scoping and changes only through a written change order, not through absorbed scope creep. The intent is clear scope on both sides: the client knows what is being paid for, what the deliverable contains, and when it lands. The firm knows the engagement boundary and operates within it.

Engagements are time-boxed against the scope. A time-boxed engagement cannot exhaustively evaluate every asset in every in-scope environment, and the engagement says so. What time-boxing produces is depth on the assets and attack paths that matter most, prioritized against the client’s actual risk profile. Where testing reveals attack paths or compliance gaps that warrant investigation beyond the time-box, the engagement surfaces them and provides scope-expansion options through a change order, rather than silently absorbing or silently dropping the work.

The same operator who scopes the engagement executes it and writes the deliverable. There is no engagement model in which a partner sells the work, a senior consultant runs it, and a junior associate writes the report. The about page covers the rationale for this operating model. The practical consequence is fewer engagements running concurrently than a larger firm would carry, better technical depth and consistency on each one, and a single point of accountability the client deals with from first conversation through delivery.

Deliverables are calibrated to the consumer who needs to act on them. Executive summaries read in plain English. Technical findings sections read at the depth a defender needs to remediate. Remediation guidance is sequenced by what produces security gain rather than by what produces a defensible-looking finding count. The standard is that a sysadmin or compliance owner can act on remediation without the tester present, and that a board member can read the executive summary in one sitting and know the disposition of the engagement.

Methodology alignment

Technical engagements (penetration testing and social engineering) run against the Penetration Testing Execution Standard. PTES provides the phase structure and the procedural discipline that makes engagements repeatable across clients. The seven PTES phases name the operating spine of the work; engagement-type specifics layer on top of it. Penetration tests reference NIST SP 800-115 for procedural cross-walk where auditors expect it, the OWASP Web Security Testing Guide for web application surfaces, MITRE ATT&CK for adversary emulation framing on red team work, and industry-specific standards (HIPAA Security Rule for healthcare scope, PCI DSS pentest guidance where cardholder data is in scope) where the client’s regulatory environment warrants them.

Compliance engagements run against the framework the organization is actually preparing for: NIST CSF, NIST SP 800-53, CIS Controls v8, ISO 27001, the HIPAA Security Rule, the SOC 2 Trust Services Criteria, the GLBA Safeguards Rule, and NIST SP 800-171 with CMMC for defense-adjacent organizations. Multi-framework engagements get cross-walked so common controls are assessed once. Hygiene assessments anchor on CIS Controls v8 Implementation Group 1 and cross-walk to NIST CSF 2.0 for strategic framing. Strategic advisory engagements anchor on framework references appropriate to the engagement type: MITRE ATT&CK for red team operations, the AWS Well-Architected Framework or Azure Cloud Adoption Framework or NIST SP 800-207 zero trust reference for architecture review, NIST SP 800-84 for tabletop exercises, and NIST SP 800-61 for incident response advisory.

The services page covers methodology specifics per engagement type. The point on this page is that framework alignment is concrete: an auditor or regulator can trace any finding back to the standard that governs it.

What the client receives and what stays with the firm

The deliverable is the client’s. The report, the findings, the underlying evidence, the remediation roadmap, and the letter of attestation are client property at delivery. The methodology used to produce them (engagement templates, analytical playbooks, snippet libraries, automation scripts, per-tool tradecraft) is firm property and stays with the firm. That separation is operationally important. Methodology is what lets the firm deliver consistent depth at fixed fee across engagements, and depth on the deliverable is what the client is paying for. This page is intentionally transparent about engagement mechanics. It is intentionally less transparent about specific tradecraft, because tradecraft published publicly stops being useful tradecraft.

Talk to us

If you are considering an engagement, reach out at contact@aegisandspear.com or through the contact page. Useful context in a first message: the question you are trying to answer, any regulatory or operational deadlines, and whether you have a specific engagement type in mind. Response within two business days.