Security Audit Report Deck

About this template

Ten slides for reporting an audit

This deck reports the result of a security audit to the people who have to act on it. It is written for an internal audit or compliance function rather than for the team being audited, which is why the two body slides are findings and required fixes, and why the closing line is “A finding closes only when it is fixed”. A vulnerability scan report looks nothing like this – slide 7 exists specifically to explain the difference.

Five agenda lines, two body pairs

Slide 2 runs findings at a glance, required fixes and deadlines, a check is not an audit, key metrics, trend analysis. The first two carry a divider and a body slide – slides 3 and 4, then 5 and 6. The comparison is slide 7, the cards slide 8, the bars slide 9. Audit scope and method, the rules a finding was raised against, and the prevention plan are not built as their own slides; duplicate the slide 5 and 6 pair for each, continue the SECTION numbering, and add the matching agenda lines.

The two body slides

• Findings at a glance: “3 critical – 11 warnings – 19 advisories”, “4 findings repeated from the last audit”, “33 violations in a sample of 240”. The repeat count is the line that changes the meeting. A finding raised twice is a process failure, not a technical one, and it belongs on the first slide rather than in an appendix.
• Required fixes and deadlines: “Critical findings fixed within 30 days”, “Filed after the dept. head signs off”, “Unfixed items carry to the next audit”. Naming who signs is what turns a finding into work.

The metric cards and the trend bars

Slide 8 holds “Findings” 33, “Critical findings” 3, “Fix deadline (days)” 30 and “Audit sample” 240. Findings and sample repeat slide 4, so the violation rate stays checkable – 33 in 240 is 13.8%, and if you change one number the rate has to be recomputed. Slide 9 falls 61, 52, 44, 33 across “H1 2024”, “H2 2024”, “H1 2025” and “H2 2025”, so it reads as findings per audit round. Half-year buckets are the right grain for a semi-annual audit cycle; if yours is annual, relabel all four rather than mixing grains. Replace the “Unit: index” label with the count you are actually plotting.

The comparison slide

Slide 7 separates “Routine security check” from “Security audit”. A check “Hunts for technical vulnerabilities”, is “Run by the team that owns the system”, and “Acting on it is left to the team”. An audit “Rules whether the requirements were met”, is “Run by an independent audit function”, and its “Deadlines and verification are mandatory”. Keep this slide when you present to a team that has been running its own scans and expects the same discretion here.

Which rules a finding is raised against

When you add a criteria slide, cite the standards this deck is written for: your own information security guidelines by article, and the Korean certification scheme the organization holds – ISMS-P for an organization certified for both information security and personal data management, ISMS where only the security scope applies. Do not restate these as SOC 2 or ISO controls for an English-reading audience. The control set, the audit cycle and the remediation obligations are different, and a finding that cites the wrong scheme cannot be closed against it. Where personal data is involved, the obligations come from Korea’s Personal Information Protection Act, including the rules on entrusting processing to a vendor.

What goes wrong

• Reporting 33 findings without the sample of 240. A count with no denominator can be argued either way.
• Setting a 30-day deadline with no owner named. The deadline slide is the only place accountability appears in a ten-slide build.
• Dropping the repeat findings into the general count. Four items coming back from the last audit is the strongest thing on slide 4 – keep it separate.