Board Technology Oversight

The Architecture Diagram the Board Should See Once a Year

Directors cannot oversee systems they have never seen drawn. One page - systems, data, key suppliers - turns oversight from vocabulary into geography.

Hand Drawing Node Structure on Paper Diagram.

Ask a director to sketch how their company's systems fit together and most will draw a laptop, a cloud, and a question mark. Then ask them to oversee the risk of that environment. The absurdity is structural, not personal: nobody has ever shown them the map.

Boards do not need network diagrams. They need one page that answers three questions: what are the core systems, where does the critical data live, and which suppliers are load-bearing. Once a year, fifteen minutes, in plain language.

With that page in hand, every other technology briefing gains a geography. Without it, oversight is a vocabulary test the board is set up to fail.

TLDR

  • One page: core systems, critical data flows, load-bearing suppliers.

  • Draw it in business language; if it needs a legend, it is the wrong diagram.

  • Review it annually and after any major system change.

  • Use it to locate every incident and every investment on the map.

  • The act of maintaining the page is itself an asset-management control.

What belongs on the page

Three layers, no more. The core systems: the handful the business cannot operate without for a week. The critical data: where customer, financial and personal information actually lives and moves - including the copies nobody brags about. The load-bearing suppliers: the platforms that would stop the business if they went dark.

Everything else - vendors of stationery, the marketing wiki, the intern's side project - stays off. The page earns its place by being short enough to read.

Why it changes the oversight conversation

With the page on the table, abstract questions become concrete. An incident is no longer 'a security event'; it is this box, holding this data, serving this function. A proposed investment stops being 'an upgrade' and becomes a change to a component the director can point at.

It also exposes the questions nobody thought to ask. This fictional example shows the annotation pattern. It is an illustration, not a real architecture.

Element on the page The question a director can now ask
Customer data in the CRM Who outside the company can reach this box?
Single payment processor What happens to this arrow on their worst day?
Legacy finance system Why is this box still here, and for how long?

Keep it true

A diagram from three re-orgs ago is worse than none, because it gets believed. Assign the page an owner - usually the technology lead - and refresh it annually and on any major system change: a new platform, a retired system, an acquisition.

The maintenance discipline doubles as asset management. NIST's framework begins with knowing what you have; the board's page is the governance-facing edge of that inventory, and the annual refresh is a forcing function that keeps the underlying inventory honest.

Fifteen minutes, once a year

The presentation is short by design: the page, what changed since last year, and the two or three areas where the map shows concentration or fragility. Directors keep the page; it is the reference for everything else they will hear about technology all year.

Over time the page builds a peculiar kind of confidence: directors who can locate a problem on the map ask sharper questions, and management, knowing the map is current, prepares better answers.

The related discussion of unified risk and innovation governance is worth your time alongside this one.

Frequently asked questions

Is showing the board an architecture diagram a security risk?

The board's version is a business diagram - systems, data, suppliers - without the technical detail an attacker would want. Directors are already entrusted with the company's deepest secrets; this is well inside that trust.

Who should draw it?

The technology lead, reviewed by the security lead and one non-technical executive. If the non-technical reviewer cannot read it, it is not done.

What if the honest answer is that nobody can draw it?

That is common, and it is the finding. Building the page - chasing down the actual systems and data flows - is one of the most useful exercises a leadership team can do, and the first draft being wrong in places is normal.

A Defensible Next Step

Ask your technology lead for the one-page map: core systems, critical data, load-bearing suppliers. If producing it takes more than two weeks, you have found the first gap it exists to reveal. Book a Decision-Clarity Call if you want the format.

Next step

Get Board-Ready on AI and Cyber Risk

A 30-minute call. No charge. You'll leave with a clear read on where your oversight stands and what to do about it.

Stop Guessing. Start Scoring
Tyson Martin

Written by Tyson Martin, NACD.DC

Chief Trust, Security & AI Officer. CISO of record at MIO Partners; former CISO & CTO at Lumber Liquidators and Orvis; advisor to 200+ Fortune 500 boards and C-suites at AWS.

See the track record
Keep reading

More on Board Technology Oversight

All CISO Insights
Board Technology Oversight

Concentration Risk in One Cloud Region

When most workloads sit in one cloud region, one failure reaches everything. A dependency heat map shows where the blast radius is bigger than intended.