This website uses cookies

Read our Privacy policy and Terms of use for more information.

Many people trying to break into GRC have not actually seen a finished audit report. A student asked about it in Simply Cyber Academy Discord last month.

When you deliver an audit, what does the workpaper look like? Is there a standard format? Do you just hand over the whole spreadsheet?

The answer varies by who you report to and what kind of audit it is. So I put a working example on GitHub that you can clone, adapt, or learn from.

It's generated directly from the CSF Profile Assessment Database, the same tool NIST features on their CSF 2.0 community resources page. You score your controls, link your artifacts, click "Generate Markdown Report," and out pops a structured document to refine for your audit committee.

The sample report covers 40 NIST CSF subcategories across Govern, Identify, Protect, Detect, Respond, and Recover functions for a fictional company called Alma Security. It's the kind of report a second line GRC team (the function that owns risk management and oversight) would hand to management, or a third line Internal Audit team would send to the board.

Here's what makes a report like this actually land with an audit committee.

Evidence is what separates a report from an opinion

A score without an artifact is just an opinion. Every rating in the Alma Security report traces back to a specific piece of evidence: phishing campaign results, SOC tickets, policy documents, CloudTrail exports, vendor evaluation matrices, endpoint inventories. When a finding shows up in the report, the reader can trace it back through the control to the artifact that backed the score.

That's the defensible management trail. Proof you're doing the work, not just checking boxes. Continuous control monitoring beats point-in-time snapshots here because it shows the work happened over the period, not just the week before the auditor showed up. The template is a starting point toward that; you fill in your own evidence as it accumulates.

Variance is what the board actually reads

The Assessment Rating Summary is the first thing the audit committee sees, and it does two jobs that matter more than any prose in the report.

First, color-coded ratings draw the eye to problem areas immediately. In the Alma Security example, Govern is satisfactory and everything else is not. The board doesn't need three pages of narrative to know where to spend their attention. They can see it in five seconds.

Second, the variance columns show movement quarter over quarter. An audit committee doesn't just want to know where you are; they want to know which direction you're heading. A "needs improvement" rating that's trending up is a very different conversation than one that's been stuck for three quarters.

Priority gaps become the headline findings

Right below the scorecard, the Top 3 Priority Gaps pulls the biggest variances to the top: ID.RA-07 Ex1, PR.IR-02 Ex1, and RS.MI-02 Ex2 in this case. These become the headline findings that drive the management response section further down, which is the section the audit committee reads first. Owner, status, target completion date for every finding. That's what turns an assessment into accountability.

The rest of the report (Independent Assessment Opinion, Executive Summary, Scope and Methodology, detailed findings) supports those headlines but doesn't compete with them.

Two reasons it's worth ten minutes of your time

If you're in GRC, clone or adapt elements of this to give your next assessment a running start. You're not building the template, you're filling it in.

If you're trying to break into GRC, this can be part of your portfolio. Start with the Alma Security case study that sits next to the template. Score it, write up findings, post your version on your GitHub. Then go a step further: open a pull request against the case study or anywhere else in the csf_profile repo. Learning in public plus a contribution to a NIST.gov-listed open source project is a real differentiator.

Have a look. Ask questions. Let me know what you build with it.

Steve

Related: A Practitioner's Tool for Implementing Cybersecurity Framework (CSF), Now Featured on NIST.gov. The backstory on why we built the CSF Profile Assessment Database.

Keep Reading