The structure of a deliverable

Security consulting is difficult to evaluate before the work is done. Two firms can quote the same type of engagement and deliver very different things at the end.

This page explains what you can expect to receive from Digital Consulting, Inc. when an engagement is complete. It is not a sample report, and it does not contain example findings, invented scenarios, or placeholder results. If you want to evaluate the work itself, the relevant public record is linked at the bottom of the page.

Scope, and its edges

Every engagement is scoped in writing before the work begins. The final deliverable restates that scope based on what was actually examined.

Sometimes the work changes once it starts. A system may contain a component that was not identified during scoping. An environment may be unavailable. Access may be more limited than expected. When that happens, the deliverable records it.

The opening section identifies the systems reviewed, the relevant trust boundaries, the assets considered important, and anything that remained outside the scope.

That last part matters. A report should not be read as assurance about systems that were never examined.

Findings, ranked by cost

Findings are prioritized according to the risk they create for the business, not simply by the severity assigned by a scanner or another tool.

A technical severity score can be useful, but it does not know your architecture, your data, your users, or how the system is actually deployed. The more useful questions are: can someone reach the weakness, what could they do with it, and what would the result mean for the business?

That context is used to decide what should be addressed first.

It also makes the findings more useful outside the engineering team. A board or executive team usually cares less about the number of findings than about which ones matter, why they matter, and what should be done about them.

The parts of a finding

Findings follow a consistent structure so that once a reader understands one, the rest are easier to work through.

The weakness

What is wrong, described in the terminology of the system rather than only as a generic vulnerability category.

The path

How the issue can be reached from a position an attacker could realistically have. A weakness exposed to the internet is not the same problem as one that requires authenticated access or an internal foothold.

The consequence

What could happen if the weakness is exploited, and what that would mean for the business.

The evidence

What was observed and why the conclusion was reached, with enough detail for the engineering team to verify it.

The owner

Who is responsible for deciding what happens next and carrying the work through.

Remediation options

A finding does not always have one correct fix.

The best approach may depend on work already underway, release timing, architectural constraints, available engineering capacity, or how much residual risk the business is willing to accept.

Where useful, the deliverable presents more than one remediation option and explains the tradeoffs. Recommendations are written with the existing architecture and development process in mind rather than as generic security guidance.

If the cost of a fix is high and the exposure is limited, that is stated directly. The goal is to support a decision, not to make every finding look urgent.

Assumptions and limits

Security work depends on assumptions, and those assumptions need to be visible.

The deliverable records anything material that was taken as given: for example, that a control was operating as described, that one environment was representative of another, or that a particular trust boundary would hold.

This gives the team a chance to correct a bad assumption before decisions are made from it.

It also makes the document more useful later. If someone returns to the report a year from now, they should be able to tell which conclusions still apply and which depended on conditions that have changed.

Intended readers

The same deliverable usually needs to work for several audiences.

Engineers need enough technical detail to understand the issue and change the system. Security or technical leadership needs to track the decisions made, the work still open, and any risk that remains. Parts of the deliverable may also be useful during a customer security review or due-diligence process.

Every engagement ends with a walkthrough of the findings and recommendations.

The document is written so that it can stand on its own, but the walkthrough gives the team an opportunity to challenge assumptions, ask questions, and discuss options that do not fit neatly into a written report.

Stated exclusions

It is just as important to be clear about what the deliverable does not represent.

There is no universal severity scale applied to every client and every system. Standard scoring systems may be referenced where useful, but prioritization is based on the system and business context.

Penetration testing is not performed as part of these engagements unless it is explicitly included in the scope. Where penetration testing is needed, the work may include defining the scope, helping select a testing provider, or reviewing and triaging the results.

Regulatory and compliance work is also limited to the agreed scope. Readiness work does not constitute certification, an audit, or a formal conformity assessment, and the deliverable will not describe it as one.

Evidence you can check

A report format by itself says very little about the quality of the work, and a polished sample report can be created by anyone.

A better way to evaluate the practice is to look at work that can be independently checked.

The published and standards record includes chapter leadership, board service, and exam item writing, with links to the organizations involved.

The technical articles show how security problems are analyzed and explained in public, in more depth than a sample deliverable could reasonably provide.

The trust center describes the engagement process, contracting entity, security practices, and the documents available to customers and procurement teams.