The deliverable is the part of vulnerability work that clients actually see. A scan finds the data, triage decides what matters, but the report is what lands in an executive inbox, gets attached to a compliance pack, or sits in an auditor’s evidence folder. When a consulting practice runs dozens of engagements at once, the way reports are produced stops being a formatting detail and becomes an operational bottleneck. This article looks at how PMAP turns report production into a reproducible pipeline, covering the six report types, the three output formats, the asynchronous generation queue, version retention, template configuration, the rule-based executive narrative, and scheduled recurring runs.
The framing matters before we start. This piece is about producing the deliverable and choosing its format. The separate question of how you deliver a finished report to an external recipient, with share tokens, passwords, encryption and integrity signing, is its own topic and is covered in secure report sharing. Here the focus is the build pipeline that exists before any link is ever sent. For the wider view of where reporting fits inside an analytics and board-reporting program, the pillar overview on vulnerability risk analytics and reporting sets the context.
Why Report Building Should Never Freeze the UI
There is a tempting but wrong way to build a report feature. The user clicks generate, the server renders the document inline, and the HTTP response carries the finished file back. It works in a demo. It falls apart the first time someone asks for a full project technical report across a few hundred findings with screenshots, severity tables and per-asset breakdowns. Rendering that document takes real time, and a synchronous request holds the connection open the entire time. The browser tab stalls, a proxy somewhere times out, and the user is left staring at a spinner with no idea whether the work succeeded or died.
PMAP avoids this by treating generation as an asynchronous job from the first line of code. When a user triggers generation, the request does not wait for the document. It enqueues the work and returns immediately with a status of queued. The document is built by a background worker, and the interface tracks progress by polling. This is not a cosmetic choice. It is the difference between a report feature that scales to a busy consulting calendar and one that buckles under the first heavy deliverable.
The benefit shows up in three places at once. The person who clicked generate gets their interface back in milliseconds rather than minutes. The server is free to process other requests instead of being pinned to one slow render. And the platform can queue several report jobs without each one blocking the next. A team running end-of-month reporting for twenty companies does not want twenty stalled browser tabs. They want twenty jobs in a queue and a list view that lights up green as each finishes.
Six Report Types for Six Audiences
A vulnerability report is not one document. The detail a penetration tester needs is noise to a board member, and the company-wide posture a CISO wants is meaningless to an asset owner triaging a single host. PMAP models this by shipping six first-class report types, each with its own data model, section layout and intended reader.
The project technical report is the full engagement deliverable. It carries finding details, severity, affected assets, CVSS context and remediation guidance, and it is the document a consultant hands to a client at the end of an assessment. The executive summary sits at the other end of the spectrum. It rolls the same project up into a leadership-facing narrative with aggregate totals and a risk score, leaving out the line-by-line detail. The company risk posture report widens the lens further to a whole company, which is the right shape for a recurring monthly or quarterly posture review.
Three more types handle the cases that do not map cleanly onto a project or a company. The selected findings report builds from an ad-hoc set of findings rather than a fixed scope, which suits a themed report such as all critical findings across an estate. The asset exposure report centres on a single asset and its active, resolved and accepted findings, useful when an asset owner needs a focused exposure sheet. The selected assets report takes an arbitrary set of assets and produces a combined view.
What makes these types more than labels is that each one drives a different ViewModel. The report type determines which sections are populated, what aggregations are computed, and which scope entity the report attaches to. The scope is derived automatically from the type rather than being set by hand. A project technical report scopes to a project, a company risk posture report scopes to a company, and an asset exposure report scopes to an asset. The caller chooses the report type and the platform works out the rest, which removes a whole class of misconfiguration where someone picks the wrong scope for the wrong report.
One ViewModel, Three Output Formats
A common trap in report tooling is to build each output format as a separate code path. The PDF generator grows its own logic, the Word export grows a parallel copy, and over time the two drift until a finding shows up in one format and not the other. PMAP avoids that by funnelling every format through a single shared ViewModel. The report data is assembled once into a format-independent model, and the renderers consume that model rather than reaching back into the database on their own terms.
From that one ViewModel, PMAP produces three formats. PDF is rendered through headless Chromium, which means the layout is driven by HTML and CSS and behaves the way a designer expects, with consistent typography, page breaks and styling. DOCX is produced by a native Go renderer that writes Word documents directly, so a client who wants to edit the report in Microsoft Word receives a genuine editable document rather than an exported approximation. HTML is available as a direct output for cases where the report needs to live in a browser or feed another system.
The single-ViewModel design pays off in a way that is easy to overlook until it bites you. Because the data is assembled once, the same report looks consistent whether it leaves as a PDF for the board pack or a DOCX for the client’s own editing. A consultant who delivers the same engagement in two formats is not delivering two subtly different documents. They are delivering one set of facts in two presentations. The official walkthrough in the project technical report guide covers the step-by-step of producing a PDF and DOCX from the same report record.
The Async Status Machine: Queued to Completed
Asynchronous generation only works if the user can see what is happening. A job that runs invisibly in the background is worse than a synchronous one, because at least the synchronous version tells you when it is done. PMAP exposes the work through an explicit status machine with four states, and the interface reflects them as live badges.
A report starts at queued the moment generation is requested. This status is set synchronously, before the request even returns, so the user immediately sees that the job is accepted. When the background worker picks the job up, the status moves to generating. On success the status becomes completed and the path to the finished file is recorded. If the render fails for any reason the status becomes failed and an error message is captured, so the user is told the truth rather than left guessing. The reports list refreshes on a short interval to track these transitions, which is why a job that finishes in the background lights up green without anyone refreshing the page.
This status machine also governs what you are allowed to do with a report. If you ask to download a report that has not finished generating, the platform does not hand back a half-written or empty file. It returns an HTTP 422 because the file does not exist yet. The download path is gated on the file actually being present, which is a small rule with a real payoff. A scheduled delivery or an automation that fires too early gets a clear, honest error instead of a corrupt attachment, and the problem surfaces at the right moment rather than landing in a client’s inbox.
Versioning So No Deliverable Is Ever Overwritten
Reports get regenerated. Findings get reclassified after a retest, a typo gets fixed, a new round of scanning lands and the client wants the document refreshed. The naive approach overwrites the old file with the new one, and the moment you do that you have destroyed evidence. The version a client signed off on last quarter is gone, replaced by a document that says something subtly different. For anyone working under audit or contractual obligations, that is not acceptable.
PMAP treats every generation as a new version rather than a replacement. Each successful run inserts a version record and writes the file to storage under a timestamped key, so previous files are never overwritten. Every version remains individually downloadable through the versions history. Regenerating a report does not erase its past. It adds to the record.
The practical value here is defensibility. If a client asks which version of a report they received in March, the answer is a specific file with a specific timestamp, not an apology that the document has since changed. If a finding was present in one version and resolved in the next, both states are preserved as artefacts rather than being collapsed into whatever the report says today. This version history pairs naturally with comparison work, where two completed reports can be diffed into new, resolved and persisting findings. That comparison angle is covered separately in vulnerability comparison analytics; the point here is that versioning is what makes those stable, named artefacts exist in the first place.
Template-Driven Sections Without Code Changes
The hardest reporting requests are not about format. They are about content shape. One client wants the executive summary first and the methodology appendix removed. A regulatory report needs a specific section ordering and a CONFIDENTIAL watermark on every page. An asset owner wants only critical and high findings in the findings table and nothing below that. If every one of these requests means a developer changing report code, the reporting feature becomes a permanent backlog item and the team that needs the report waits weeks.
PMAP moves this control out of code and into templates. A report template defines what a generated report contains and how it looks: which sections render and in what order, what findings qualify for each section, optional custom free-text blocks, column selection, watermark text and severity mapping. The configuration is stored as structured data and applied at generation time, so changing the shape of a report is a configuration change rather than a code change.
The section configuration is where most of the power sits. Each template carries an ordered list of sections, and each section can carry conditional rendering rules. A section can be set to render always, to render only when there are findings to show with has_findings, or to render only when at least one finding of a given severity is present with has_severity:<sev>. This means a report can adapt to its own data. An empty resolved-findings section simply does not appear rather than printing a hollow heading, and a section reserved for critical findings stays out of the document when there are none. Per-section finding filters layer on top, restricting individual sections by severity, status, a limit and a sort order, so the findings table can show one slice of the data while a detailed appendix shows another.
Custom text blocks fill the remaining gap. A free-text block can be injected after any named section, which lets a team add branded narrative, a methodology statement, or regulatory boilerplate without touching code. Templates also carry a regulatory classification, with flags that mark a template as produced for a specific compliance framework such as ISO 27001 or PCI-DSS, surfaced as a badge in the template library so the right template is easy to find.
System Templates and Clone-to-Edit
A template library that anyone can edit in place is a library that eventually breaks, because someone modifies the shared baseline and every report that depends on it changes underneath the people using it. PMAP separates curated baselines from user customisation with a simple rule. System templates are read-only. They ship with the platform and cannot be modified or deleted through the API. An attempt to change one is refused with a clear message that tells the user to clone the template to create a custom version.
That clone-to-edit model gives a team a stable starting point that never drifts and full freedom to customise their own copies. The original system template stays pristine as a reference, and the custom variant carries whatever section ordering, filters, watermark and blocks the team needs. Before committing to a template, the live preview renders it to HTML against synthetic sample data, applying the real section configuration and watermark, so an author can see the shape of a report without generating a real document against live findings. The preview is shown in an embedded frame, which means template design is a fast feedback loop rather than a guess-and-generate cycle. The hands-on path for cloning a template and wiring its sections is covered in the project technical report guide.
Rule-Based Executive Narrative in EN and TR
Executives do not read finding tables. They read sentences. A report that hands a board member a grid of CVEs and severities has done the technical work and skipped the communication work. The gap between raw findings and a narrative a leader can act on is real, and the easy answer in 2026 is to throw the data at a large language model and ask it to write the summary.
PMAP takes a deliberately different path. Its executive narrative is generated by a rule-based, AI-free engine that produces a seven-section narrative directly from the report data. There is no external model call, no token cost and no risk that a hallucinated sentence ends up in a client deliverable. The narrative is deterministic, which means the same data produces the same prose, and the same data audited twice tells the same story. For a document that may become compliance evidence, that predictability is a feature rather than a limitation.
The narrative is available in both English and Turkish, and it can be previewed live through the interface before the file is regenerated. An author can read the generated summary, confirm it reflects the engagement, and regenerate the document with confidence. Because the generation is local and rule-based, this preview is instant rather than a round trip to an external service. For an organisation that cannot send vulnerability data to a third-party model for governance reasons, a narrative engine that runs entirely inside the platform is the difference between using the feature and disabling it. The wider security community treats clear, audience-appropriate reporting as a core part of an assessment, a position reflected in the reporting guidance of the OWASP Web Security Testing Guide and the reporting phase of the Penetration Testing Execution Standard.
Scheduled and Recurring Generation
The most repetitive reporting work is also the most predictable. A monthly company risk posture report, a weekly findings summary, a quarterly executive review: these are reports that someone generates by hand on a calendar, and every manual generation is a chance to forget, to run it late, or to run it twice. The whole point of a recurring report is that it should not depend on a person remembering.
PMAP supports both one-time and recurring schedules. A one-time schedule fires a report at a chosen future moment, which is useful for a deliverable that needs to be ready by a specific date. A recurring schedule uses a cron expression to fire on a daily, weekly, monthly or yearly cadence, and a background runner fires due reports automatically without anyone watching the clock. The team configures the cadence once and the platform handles the rest.
The scheduling logic carries a detail that matters more than it first appears. Before a scheduled report fires, the runner clears the schedule, and only then triggers generation. This ordering prevents a slow generation from being triggered twice if the runner ticks again while the first run is still building. A recurring schedule is preserved across runs so the cadence continues, while a one-time schedule is cleared after it fires so it does not repeat. The result is that a monthly report runs once a month, not twice because the document took longer to build than the interval between ticks. Scheduled generation also slots naturally into broader automation, where a runbook can produce a report as one step in a larger workflow, which is explored in the automation cluster.
Branding, Watermark and Regulatory Classification
A deliverable that does not look like it belongs to the client undercuts the work inside it. Reports carry branding so the output reads as a professional document rather than a raw export. The client name and the company logo appear on the cover, the platform branding is applied consistently, and the report language is selected per report so the same engagement can be delivered in English or Turkish with a full translation applied throughout rather than a half-translated document.
Watermarking and severity mapping handle the more specialised requirements. A template-level watermark overlays text such as CONFIDENTIAL across the report, which is the kind of marking a regulated or sensitive deliverable needs as a matter of policy. Severity mapping lets a template remap the scanner’s severity labels onto a different display scale, which matters when a client or a regulator uses a severity vocabulary that does not match the scanner’s native one. A report produced for a specific framework can be flagged with a regulatory classification, marking it as a regulatory document of a named type so it is unambiguous in the library and in the output. None of these touches require code. They are template and report configuration, which keeps the people who own the report in control of how it looks.
These content and format choices align with the structure that established testing standards expect from a report. The content guidance in NIST SP 800-115, the technical guide to information security testing, describes the kind of structured, audience-aware reporting that a configurable template system is built to produce.
How PMAP Produces Reproducible Deliverables at Scale
Pull the threads together and a clear shape emerges. Generation is asynchronous, so the interface never freezes and a busy reporting calendar runs as a queue rather than a series of stalled tabs. Six report types map the right level of detail to the right reader. A single ViewModel feeds three output formats, so PDF, DOCX and HTML stay consistent rather than drifting apart. Every generation is versioned, so no deliverable is ever overwritten and every past report remains an artefact. Templates move the shape of a report out of code, so a new section order, filter or watermark is a configuration change. The executive narrative is rule-based and runs locally, so the leadership summary is deterministic and never leaves the platform. Scheduling makes recurring reports unattended without the double-fire risk that naive schedulers carry.
The common thread is reproducibility. A report in PMAP is not a one-off render that happens to look right today. It is a versioned artefact produced from a defined type, a configured template and a known set of findings, in a format the recipient asked for, on a schedule the team set once. For a consulting practice that lives or dies on the quality and consistency of its deliverables, that turns reporting from a recurring scramble into a pipeline. Once the document exists, the next question is how to get it into the right hands safely, which is exactly where secure report sharing picks up the story.
Read the reporting datasheet and generate your next branded deliverable in PDF or DOCX.
Frequently Asked Questions
What report formats can PMAP generate?
PMAP generates reports in three formats from a single shared data model: PDF rendered through headless Chromium, DOCX produced by a native Go renderer for genuine editable Word documents, and HTML for browser or downstream use. Because all three formats consume the same ViewModel, the same report stays consistent across formats rather than drifting between them.
Why is report generation asynchronous?
Building a full report can take real time, and a synchronous request would hold the connection open and freeze the interface for the duration. PMAP enqueues generation and returns immediately with a queued status, then a background worker builds the document while the interface tracks progress through a queued, generating, completed or failed status machine. This keeps the UI responsive and lets several reports queue without blocking each other.
What are the six report types in PMAP?
PMAP ships six report types: project technical, executive summary, company risk posture, selected findings, asset exposure and selected assets. Each has its own data model and section layout, and the scope is derived automatically from the type, so a project technical report scopes to a project, a company risk posture report scopes to a company, and an asset exposure report scopes to an asset.
Does regenerating a report overwrite the previous file?
No. Every successful generation creates a new version with a timestamped storage key, so previous files are never overwritten and every version remains individually downloadable. This keeps each report a stable artefact, which matters when a client or auditor needs the exact version they received at a point in time.
Can I change what a report contains without code changes?
Yes. Report templates define the ordered list of sections, conditional rendering rules such as render only when findings exist, per-section finding filters, custom free-text blocks, column selection, watermark text and severity mapping. All of this is configuration applied at generation time, so changing the shape of a report does not require touching code. System templates are read-only and are cloned to create editable custom variants.
Does the executive narrative use AI?
No. The executive narrative is produced by a rule-based, AI-free engine that generates a seven-section summary directly from the report data in English or Turkish. There is no external model call, which means the output is deterministic and the report data never leaves the platform. The narrative can be previewed live before the file is regenerated.
Can reports be generated on a schedule?
Yes. PMAP supports one-time schedules that fire a report at a future moment and recurring schedules driven by a cron expression on a daily, weekly, monthly or yearly cadence. A background runner fires due reports automatically and clears the schedule before firing to prevent a slow generation from being triggered twice. Recurring schedules are preserved across runs while one-time schedules clear after firing.
