So far, we've looked at the findings in the report.
Now we need to see everything else.
Why is anything else important at all? In this module, we're looking at
all the other pieces that go into making a good report.
We need to understand why we're putting other details in there.
The why should really drive what we're writing.
We'll look at the other sections Kim has put into her report, and for
each one, we'll ask why. If there isn't a good reason,
then it shouldn't be there.
The who is also a big part of this module. In the last
module, that was mostly Vincent,
our security engineer. He was technical and needed technical details.
Here, the primary who is Chris, our IT manager.
Chris is interested in the results,
but more from a high level. The technical details aren't so important.
That's because Chris isn't fixing them,
but he is responsible for understanding how the findings in
the report might impact the business.
He needs to understand the risks they present so
the business can plan a response.
Not all of the responses will be technical.
For example,
some might be to ensure certain processes are in place, like timely operating
system patches, or the test results could highlight a lack of logging and
monitoring of security events. Purchases and training might be part of the
solution. Revisiting our goals for the report, we've already detailed the
vulnerabilities at a technical level, but we haven't finished with this yet.
We need to make sure the business understands them too.
We've also stated mitigations at a technical level,
but again, the business will need some context that isn't technical.
Finally, we've looked a little at highlighting the risks,
but that's much more about the business than the technical teams.
We need some more effort to meet this goal. Globomantics is
performing a pen test for Carved Rock, so it's performed by a third party.
Some businesses do have internal pen test teams, and the
structure of a report there may take a different form,
driven by internal requirements.
The audience is more well defined so the content can be more specific to them.
As this is a third‑party report, the intent is to be more generic
in terms of the stakeholders it targets. Kim may not have a clear
view on how technical those people are.
The non‑technical side of the report,
therefore, has to be readable by an audience with a
varying degree of technical knowledge.
It needs to target the less technical end of the scale,
but still get across the risks