The security metrics platform that told executives how much to trust each number

Apple InfoSec ran on a small BI team that hand-built metrics for every partner team. Coverage sat under 30%. Getting one new metric published took about two months. By the time a metric went live, it was often stale.

That left senior executives without a quantitative answer to the one question that mattered: how well are we keeping Apple safe? In board-level conversations they were using thumbs-up and thumbs-down emojis.

I replaced the static reporting site with a governed self-service intelligence platform. Every metric on it carries a visible trust level.

The BI team was the only path to a published metric. A request moved through four steps. Define the measure. Negotiate the formula. Chase data engineering. Publish. Average time was two months.

Because the queue was slow, teams stopped waiting. They built their own dashboards. Those dashboards held real metrics that never entered the central platform. So executives now had two problems instead of one. The central view was incomplete, and the numbers they heard in meetings did not match the numbers on the platform.

When a metric spiked, an executive had no way to check it themselves. They picked up the phone. That started a chain of formal and informal assurance calls across teams, repeated for every stakeholder who asked.

I started with a design sprint with the BI team to map how a metric actually gets made. Then I ran interviews on both ends of the pipe. Six metric authors from partner security orgs. Two executives who consume the output.

The authors told me the bottleneck was negotiation, not effort. They knew their own data. They were waiting on someone else to agree on a formula.

The executives told me something I did not expect. Their problem was not missing data. It was not knowing which numbers were solid. They had learned to discount anything they could not trace.

When I joined, the team had already split the work into two separate tracks. Track one was to standardize and speed up metric onboarding. Track two was to build a security impact framework that answered the executive question directly.

I argued for a single solution: self-service.

My reasoning was simple. If each team can onboard its own metrics, then each team's own clarity and speed decides its coverage. The BI queue stops being the limit. And once a team has that autonomy, it has no reason to spin up a shadow dashboard.

There was a second win. A self-service platform generates its own usage data. That gave the BI team quantitative evidence to show their own leadership, who were also their customers.

I got buy-in by showing that track two was a reporting layer on top of track one. It could not exist without coverage, and coverage could not exist without speed.

The moment anyone can publish a metric, every metric stops being equal. A metric vetted by the BI team and a metric published by a partner team on a Friday afternoon would sit on the same page, in the same card, at the same size.

So the executive question changed. It moved from "where is the number?" to "how much can I trust this number?"

That became my core design problem. Make the trust level visible on every metric, at every level of the interface.

I designed a badge system attached to every metric. My first version had three badges: Self serviced, BI vetted, and BI led.

That version failed in review. "BI vetted" and "BI led" read as the same thing. Executives could not tell them apart, and a badge that needs explaining is a badge that does not work. I cut it down. "BI vetted" became "Vetted". "BI led" was removed entirely. Two states, clearly different.

Alongside the badge, I surfaced data lineage for every metric. An executive can open any number and see where it came from, who owns it, and how fresh it is. That turns a discount decision into an informed decision.

The badge never relies on color alone. Each state carries a distinct label and shape, so it holds up for color-blind readers and in printed board decks.

The original process reviewed quality after an onboarding request was submitted. That meant the BI team spent its time sending work back.

I put the quality gates inside the authoring flow. An author cannot advance until the metric has a clear definition, a stated formula, a named owner, a declared source, and a freshness expectation.

The result is that a badly formed metric never reaches the catalog. The gate does the rejecting, and the BI team stops being the bottleneck for basic hygiene.

The trade-off is real. Authoring takes more effort up front. I accepted that because the alternative was cleanup work spread across the whole team, forever.

The second big cost was what happened when a metric spiked. An executive saw a jump, called the owning team, got a verbal explanation, then repeated that explanation to other stakeholders. Every spike triggered a chain of escalation calls.

I designed an AI-assisted anomaly detection and analysis flow to absorb that work. The system detects the anomaly, drafts an explanation, and routes it to a human reviewer on the owning team. The reviewer edits or rejects it before it publishes.

The design rule I held to was transparency. The executive sees the draft, the reviewer, the edits, and the final note. The iterations stay visible. A conclusion that arrives without its working is a conclusion nobody can defend in a board meeting.

I also chose a standardized detail view built on statistical process control. That gives every metric the same read for what counts as normal variation.

The trade-off: a new metric has no history, so it cannot produce meaningful control limits yet. We accepted a warm-up period where the detail view says so plainly instead of showing limits it cannot support.

Design execution speed was its own problem. I solve that by building the system the work runs on.

I authored an AI-ready markdown specification of Apple's Human Interface Guidelines. Then I authored a second one for shadcn/ui, the framework the team was already using. Both files are written so an AI tool can read them and produce on-system output on the first pass.

On top of those two files, I built the design system for the platform.

It did three jobs at once. It let me ideate and iterate fast. It let non-designers on the team produce work that stayed on-system. And it gave developers an exact token taxonomy at handoff, so the spec and the build spoke the same language.

Metric coverage moved from under 30% to over 85%.

Average onboarding time dropped from two months to under one week.

Escalation calls during incidents dropped by roughly 75%. That figure comes from the teams themselves, reported in conversations after a one-month pilot with eight teams. It is team-reported, not instrumented, and I present it that way.

The change that mattered most is harder to put a number on. Executives stopped reacting to metrics with emojis and started asking about lineage and badge state.

My first design hid all self-service metrics from the executive view. The logic seemed sound at the time. Protect executives from unvetted data.

It failed. Hiding the metrics recreated the original problem. Executives were back to an incomplete picture, and the teams whose metrics were hidden had no reason to use the platform.

I reversed it. Every metric now appears with equal visual weight, and the badge carries the difference. Let people see everything, and tell them plainly how much each thing is worth.

One problem is still open. When the AI drafts are usually correct, the human review turns into a click. A high approval rate is not evidence that oversight happened. I do not have a clean answer for this yet. My current thinking is to measure review time and edit rate instead of approval rate, and to sample drafts for blind re-review. That work sits with the team now.