How to Read a Board Security Report: Five Questions That Matter

What should a board security report actually tell us?

It should tell you where you stand, what changed, and what you need to decide. Charts of blocked attacks and patch counts rarely do that. They measure activity, not risk.

Ask for the trend, not just the snapshot. A score that rose for three quarters tells a different story than one that stalled.

Each report should end with the decisions it needs from you. If there are none, ask why.

What are we protecting, and where does it live?

This comes first because every other answer depends on it. Your report should name the data that matters and the systems that hold it.

For most defense contractors, that means Controlled Unclassified Information, or CUI. It may also mean Federal Contract Information, covered by FAR 52.204-21. Some firms also hold ITAR technical data.

Ask where the boundary is drawn. A tight boundary keeps the rules focused on fewer systems. A loose one spreads them across every laptop and cloud account.

ITAR data adds a second question: who can see it. Under ITAR, releasing technical data to a foreign person can count as an export, even inside your own building.

The CISO should own this map. The board should know it exists and when it last changed.

Are we meeting the security rules we promise the government?

DFARS 252.204-7012 requires you to protect CUI using NIST SP 800-171 Rev 2. That standard has 110 requirements. Your report should say how many you fully meet today.

Your self-assessment score is posted in SPRS, a DoD system. It is not graded on a curve. It can even fall below zero.

Gaps go on a plan of action. Ask who owns each gap and when it will close.

CMMC limits which gaps can sit on a plan and for how long. A plan that keeps slipping is a risk in itself.

Then remember the affirmation. The official who signs should be able to trace each claim back to proof. The Department of Justice has used the False Claims Act against contractors who misstated their cyber compliance.

Which risks are we accepting, and who signed off?

Every company carries some risk. The danger is carrying it without knowing. Your report should list the risks leadership has chosen to accept.

Each one needs an owner by role, a reason, and a review date. "We know, and we decided" is a sound answer. "Nobody looked" is not.

Watch for business risks that were quietly left with IT. Delaying a system upgrade may save effort this year. The choice to carry that risk belongs to leadership, not the help desk.

Are we ready if something goes wrong tomorrow?

DFARS 252.204-7012 requires you to report a cyber incident to DoD within 72 hours of discovery. That clock runs fast. Your report should say whether you could meet it.

Ask who decides that an event must be reported. Ask whether you hold the DoD certificate you need to file the report.

Then ask when you last practiced. A practice run that found problems is good news. A plan no one has tested is not.

Could we prove it if an assessor checked?

A claim without proof will not hold up. NIST SP 800-171A explains how assessors check each requirement. They examine documents, interview people, and test systems.

Ask your CISO to pick one requirement each quarter. Then show the board the evidence behind it. This builds trust faster than any dashboard.

If the evidence is thin, that is your real status. Treat the score as unproven until proof backs it.

Where are the sources?

NIST SP 800-171 Rev 2: https://csrc.nist.gov/pubs/sp/800/171/r2/upd1/final

NIST SP 800-171A: https://csrc.nist.gov/pubs/sp/800/171/a/final

FAR 52.204-21: https://www.acquisition.gov/far/52.204-21

32 CFR Part 170, CMMC Program: https://www.ecfr.gov/current/title-32/subtitle-A/chapter-I/subchapter-G/part-170

DoD CIO CMMC program page: https://dodcio.defense.gov/CMMC/