A penetration test is rarely a single person running a single tool against a single host. In an enterprise programme it is a coordinated engagement. Several testers, sometimes several consulting firms, work against a defined target surface, over a defined window, against a contracted budget, and everything they produce has to be traceable afterwards. The moment you accept that reality, the spreadsheet stops being enough.
Pentest project management is the discipline of turning a loose collection of scans, testers, and reports into one governed unit of work. In PMAP, the project is that unit. It bounds who is in scope, who is doing the work, how much effort is contracted, which findings belong to the engagement, and what audit trail is left behind. This article explains how PMAP structures a multi-firm pentest project, why each control exists, and how leads use the governance layer to keep complex engagements honest.
If you want the broader strategy view first, the pillar on security assessment management frames where projects sit in the full assessment lifecycle. This piece goes one level deeper into the project container itself.
From Ad-Hoc Pentests to Governed Projects
Most teams start the same way. A pentest is requested, an engineer fires up a scanner, results land in a document, and a report follows. That works exactly once. As soon as you run the second engagement, the questions start. Which assets were actually tested last time? Who tested them? Did we burn the man-days we contracted for? Where is the evidence for the critical finding we reported in March? Ad-hoc testing has no answer to any of these questions because it has no container to hold the answers.
PMAP treats the project as a governance container rather than a folder. A project wraps a penetration test, a scan campaign, or a recurring security review. It defines who is in scope through three-mode scope, who is doing the work through members and consulting firms, what the timeline and effort targets are, and which findings, scans, and assessment runs belong to it. Everything downstream carries a project_id that traces back to this container. A finding is never an orphan. A scan is never a loose artefact. Each one resolves to the engagement that produced it.
That resolution is what makes governance possible. Because every finding, scan, and run points back to a project, the platform can answer the awkward questions automatically. It knows what was tested, by whom, and when, and it keeps that record without anyone maintaining a separate ledger by hand. The project also enforces a set of rules that a folder never could. It rejects duplicate names within a company, validates the commercial agreement behind the work, tracks man-day burn, aggregates evidence, and emits a compliance audit event when a project is deleted. Those rules are the difference between a place to store work and a layer that governs it.
The shift from ad-hoc to governed is not about adding bureaucracy. It is about making the engagement queryable. When the project is the unit of truth, a programme running dozens of concurrent engagements across multiple firms stays legible instead of dissolving into a pile of disconnected documents.
Defining Scope in Three Modes
Scope is the first thing a project lead defines and the most consequential. It decides what the testers are allowed to touch and what the platform will let them launch a scan against. PMAP does not force you into one way of expressing scope, because real target surfaces do not come in one shape. It offers three modes, and each is managed independently.
The first mode is individual asset pins. You pick specific assets and add them to the project scope one by one. This suits a tightly defined engagement where the target list is short and known in advance, for example a named set of internet-facing applications agreed in the statement of work.
The second mode is asset-group pins. Instead of pinning assets individually, you pin a whole asset group. This reuses inventory grouping you have already built, so a project that targets the entire production web tier can reference that group rather than re-selecting every host. When the group is dynamic, the project scope inherits whatever the group resolves to.
The third mode is attribute-based selectors. Here you describe the target surface by pattern rather than by enumeration. Selectors support IP addresses, CIDR ranges, IP ranges, URLs, hostnames, and wildcard domains. A selector of 10.0.0.0/24 expresses an intent. The platform resolves that intent against inventory and reports back how many assets matched.
That matched count is not cosmetic. Each attribute selector reports a matched_count and an unmatched_count, so a lead knows the real coverage of the scope before any work begins. If a selector for a CIDR block resolves to far fewer assets than expected, that gap is visible immediately rather than discovered mid-engagement when a tester notices a host is missing. The three modes coexist on the same project, which means a single engagement can pin a few critical assets, reference a group for the bulk of the surface, and add a wildcard selector for everything under a domain, all at once.
Why a Scope-Gated Scan Prevents Zero-Asset Runs
There is a specific failure mode that scope solves. An analyst opens a project, goes to launch a scan, and the scope is empty because nobody finished defining it. Without a guardrail, the scan launches against nothing, consumes a slot, and produces a confusing zero-result run that someone later has to investigate.
PMAP closes that gap at the interface. The new scan wizard is disabled when the project scope is empty. The launch control is simply not available until the scope count is greater than zero. The platform refuses to let an analyst run an accidental zero-asset scan, which removes a whole class of wasted runs and the cleanup they cause. It is a small rule with an outsized effect on day-to-day hygiene, because it makes the correct order of operations the only available order. Define scope, then scan.
Bringing Multiple Firms Into One Engagement
Joint engagements are common in enterprise security. A primary firm leads the test, a specialist subcontractor handles a particular surface, and an independent firm performs quality assurance or audit. Modelling that as a single anonymous team breaks the commercials and the accountability. PMAP models it as what it is, a set of distinct firms each with a defined role.
The multi-firm engagement panel lets a project lead assign multiple consulting firms to one project. Each firm carries its own role, its own man-day allocation, and its own date range. The available firm roles are primary, secondary, subcontractor, auditor, and qa. If a role is not specified when a firm is added, it defaults to secondary. An invalid role value is rejected outright with a 400 error rather than being silently accepted, so the engagement record never holds a role nobody recognises.
Per-firm man-days and per-firm date ranges are what make joint engagements commercially accurate. A subcontractor brought in for a two-week window with a 10-day allocation is recorded with exactly those figures, separate from the primary firm’s larger budget and longer window. When the time comes to reconcile what each firm delivered against what each firm contracted, the data is already separated by firm rather than blended into one project-wide total.
The panel also guards against the obvious mistakes. Linking a firm that is already linked returns an “already linked” error rather than creating a duplicate engagement row, and attempting to remove a firm that was never linked returns a “not linked” error rather than a generic failure. These specific responses matter operationally, because they tell the lead precisely what state the engagement is in instead of leaving them to guess.
Linking a Framework Agreement for Man-Day Tracking
A pentest firm does not usually sell one project at a time. It sells contracted capacity, often a framework agreement that covers a pool of man-days across many engagements over a contract period. The hard part is knowing, at any given moment, how much of that pool is left. Done by hand, this is a spreadsheet that is always slightly wrong because someone forgot to update it after the last project changed.
PMAP links a project to a framework agreement and then does the accounting itself. When a framework_agreement_id is supplied on a project, the platform validates the link before accepting it. The agreement’s company must match the project’s company, and if the project has a consulting firm set, the agreement’s consulting firm must match as well. A mismatch is rejected with an agreement mismatch error, so a project can never be quietly charged against the wrong contract or the wrong customer. There is one deliberately softer case. If the agreement is project-based and already has a linked project, attaching a second project succeeds but returns a non-blocking warning, so the lead is told they are stretching a single-project agreement without being hard-stopped.
The accounting itself runs through recalculation. On every create, update, or delete that touches a framework agreement, the platform calls its man-day recalculation synchronously within the same request. The agreement’s used man-days figure is recomputed immediately, not on a nightly job and not when someone remembers to refresh. The result is that the remaining capacity shown against an agreement is accurate the instant a project changes. Add a project that consumes 20 days and the agreement reflects it at once. Delete a project and the days return to the pool in the same breath.
This article keeps the agreement story at the level of how a project consumes capacity. The deeper mechanics of framework agreements, vendor qualification records, and the capacity gauge live in their own piece. If you are managing contracted capacity across many vendors, the companion article on framework agreements and man-day budget control covers that surface in full.
Planned vs Actual Man-Days
A budget is only useful if you can see consumption against it. Every project tracks two effort figures. Planned man-days are what the engagement was scoped to cost. Actual man-days are what it actually consumed. The project overview surfaces both as KPI figures and renders a utilization bar that shows the relationship between them at a glance.
The value of separating planned from actual is that it makes overruns visible while there is still time to act. A project sitting at 90 percent of its planned days with significant work remaining is a problem you want to see in week two, not in the closing report. Because the utilization bar is part of the overview rather than a buried metric, a lead reviewing a portfolio of active engagements can spot the one that is burning faster than planned and intervene. Planned versus actual is the simplest possible signal, and that simplicity is exactly why leads watch it.
Members and Roles Inside the Project
Firms describe the commercial structure of the engagement. Members describe the people doing the work. PMAP keeps these separate because they answer different questions. A firm answers who is contracted. A member answers who has access and what they are allowed to do inside the project.
Project members are users added with a role. The valid member roles are lead, tester, reviewer, and observer. A lead configures and drives the engagement. A tester does the hands-on assessment work. A reviewer checks the output. An observer, often a client security manager, watches status and trends without changing anything. If a member is added with a role value the platform does not recognise, it is silently normalised to tester rather than rejected, so an unexpected role never blocks someone from being added but also never grants more than the baseline working role.
The separation of member roles from firm roles is what lets a multi-firm engagement stay coherent. A subcontractor firm can have several individual testers as members, a client can have a security manager added as an observer, and the primary firm’s lead drives the whole thing, all inside one project with each person carrying the access their role implies. A user can also see every project they belong to in one place, with their role and open-finding counts across all companies, which gives a tester working across several concurrent engagements a single view of their workload.
Per-Project SLA Policy Overriding the Company Default
Most platforms apply one set of remediation deadlines across the whole organisation. That works until a specific engagement carries a contractual SLA that differs from the house default. A high-assurance customer might contract tighter remediation windows than the standard policy, and the project needs to honour that contract rather than the company-wide setting.
PMAP allows a per-project SLA policy that overrides the company default. A project can define its own SLA hours by severity, governed to whatever the engagement’s contract specifies. Crucially, the override is not just a stored preference. When the policy is set and recalculation is triggered, the SLA deadlines on every finding in the project are updated to reflect the new policy. The recalculation reaches into the findings that already exist and rewrites their deadlines, so the change applies to the whole engagement rather than only to findings created after the policy was set.
That recalculation behaviour is what makes the override trustworthy. A lead who tightens the SLA partway through an engagement does not have to wonder whether older findings are still running on the old clock. They are not. The policy change propagates to every affected finding, and the deadlines reflect the contract the project is actually governed to.
Reading the Wave Timeline Across the Engagement
A pentest engagement that runs over weeks is not a single snapshot. It is a sequence of scan waves, and the interesting story is how risk moves between them. PMAP surfaces that story in the wave timeline, a chronological view of the scan waves inside a project.
Each wave entry reports finding deltas. For a given wave the timeline shows how many findings are new, how many are persisting from earlier waves, how many were resolved, and how many reopened after having been closed. Alongside the deltas it shows a severity breakdown, so a wave is not just a count but a shape. A wave that resolves twenty mediums while three new criticals appear tells a very different story from a wave that closes the criticals and leaves only low-severity noise, and the timeline makes that difference legible at a glance.
The reopened count deserves its own attention. A finding that was closed and then reopened in a later wave is a regression, and regressions are exactly the signal an engagement lead needs to escalate. Something that was fixed has come back, which usually means a remediation did not hold or a deployment reverted it. Because the timeline tracks the closed-to-reopened transition per wave, those regressions surface as a number rather than as an anecdote someone happens to remember.
The timeline also supports comparison. A lead can select up to two runs and place them side by side to diff one wave against another directly. This turns “is the engagement getting better or worse” from a feeling into a comparison you can read off the screen. The granular mechanics of assessment runs, wave numbering, and the completion delta sit in the companion article on assessment runs and scan campaigns; the project timeline is where those runs are read together across the whole engagement.
Evidence Aggregation and Compliance Audit
When a pentest engagement closes, two things have to be true. The evidence has to be findable, and the record has to survive scrutiny. PMAP handles both at the project level rather than leaving them to manual collation.
Evidence aggregation solves the findability problem. Findings accumulate attachments throughout an engagement, screenshots, proof-of-concept output, supporting files, and in most tools these are scattered across individual findings. The project evidence panel pulls all finding attachments across the project into one aggregated view, and it enriches each attachment with the title and severity of the finding it belongs to. An analyst preparing a deliverable does not have to open finding after finding to gather the proof. The evidence for the whole engagement is in one place, already labelled with what it proves and how serious it is.
Compliance audit solves the survivability problem. Deleting a project is a significant act, and it cannot be allowed to erase the fact that the engagement existed. When a project is deleted, PMAP emits a compliance audit event that captures the pre-delete metadata, including the project name and company, for SOC2 traceability. The deletion removes the working container, but the audit trail retains the record that a project by that name, for that company, existed and was removed. An auditor asking what happened to a past engagement gets an answer rather than a void.
Beyond deletion, project create, update, and delete operations also emit best-effort events that fan out to notification and analytics, so the rest of the platform stays aware of the engagement’s lifecycle. The governance is not a single checkpoint at the end. It runs throughout the life of the project.
How PMAP Governs Multi-Firm Engagements
Put the pieces together and a pattern emerges. PMAP governs a multi-firm pentest engagement by making the project the single container that everything resolves to, then enforcing rules at every edge of that container.
Scope decides what is in play, and the three-mode editor lets you express any target surface without redundant data entry, while the scope gate refuses to let work start against nothing. Firms describe the commercial structure, with distinct roles and per-firm budgets that keep joint engagements accurate. The framework agreement link keeps capacity honest, recalculating used man-days the instant a project changes so the contracted pool is never out of date. Members describe who has access and at what level. The per-project SLA override lets each engagement be governed to its own contract, propagating deadlines to every finding it touches. The wave timeline turns the sequence of scans into a readable story of how risk moved, with regressions surfaced as numbers. Evidence aggregation makes the proof findable, and the compliance audit makes the record durable.
None of these controls is decorative. Each one answers a question that an enterprise security programme has to answer about every engagement it runs. What was tested, by whom, under which contract, against which budget, with what result, and where is the evidence. Because the project holds the answers and enforces the rules that keep them true, a programme can run dozens of concurrent multi-firm engagements and still know, at any moment, exactly where each one stands.
That is the governance layer in practice. It does not make the testing itself easier. It makes the engagement around the testing legible, accountable, and auditable, which is what turns a sequence of pentests into a managed assessment programme.
Ready to structure your next engagement this way? Read the assessment and engagement datasheet and structure your next multi-firm pentest in PMAP. For the hands-on procedure of building the project and adding firms step by step, the companion guide on planning a pentest project with a multi-firm engagement walks through the exact configuration.
Frequently Asked Questions
How do I scope a pentest project in PMAP?
PMAP supports three independent scope modes on the same project. You can pin individual assets one by one, pin entire asset groups to reuse inventory grouping you have already built, or add attribute-based selectors that describe the target surface by pattern. Selectors accept IP addresses, CIDR ranges, IP ranges, URLs, hostnames, and wildcard domains, and each selector reports a matched count and an unmatched count so you see real coverage before any work begins. A single engagement can combine all three modes at once.
Can multiple consulting firms work on one project?
Yes. The multi-firm engagement panel lets a project lead assign several consulting firms to one project, each with its own role, man-day allocation, and date range. The available firm roles are primary, secondary, subcontractor, auditor, and QA. A missing role defaults to secondary, and an invalid role value is rejected with a 400 error. Per-firm budgets and date ranges keep joint engagements commercially accurate because each firm’s contribution is tracked separately rather than blended into one project total.
How are man-days tracked against a framework agreement?
When a project is linked to a framework agreement, PMAP recalculates the agreement’s used man-days synchronously on every create, update, or delete that touches the agreement. The figure is recomputed within the same request rather than on a scheduled job, so remaining capacity is accurate the instant a project changes. The link is also validated at write time. The agreement’s company and, where set, its consulting firm must match the project, and a mismatch is rejected.
Can a project have its own SLA policy?
Yes. A project can define a per-project SLA policy that overrides the company default, setting its own SLA hours by severity to match the engagement’s contract. When the policy is set and recalculation runs, the SLA deadlines on every finding in the project are updated to reflect the new policy, so the change applies to existing findings rather than only to ones created afterwards.
What stops an analyst from running a scan with no targets?
The new scan wizard is disabled whenever the project scope is empty. The launch control is unavailable until the scope count is greater than zero, which prevents accidental zero-asset scans and the wasted runs and cleanup they cause. In practice this enforces the correct order of operations, define scope first, then scan.
How does the wave timeline help during a long engagement?
The wave timeline shows the scan waves inside a project in chronological order, and each wave reports how many findings are new, persisting, resolved, and reopened, plus a severity breakdown. The reopened count flags regressions, where something that was closed has come back. A lead can also select up to two runs and compare them side by side, which turns the question of whether risk is improving or worsening into a comparison you can read directly.
What happens to the record when a project is deleted?
Deleting a project emits a compliance audit event that captures the pre-delete metadata, including the project name and company, for SOC2 traceability. The working container is removed, but the audit trail retains the record that the engagement existed and was deleted, so an auditor reviewing past activity gets an answer rather than a gap.
