FIELD NOTES / PRODUCT DESIGN
Beyond the Audit: Scoring Controls
The maturity dashboard compares current maturity to targets across every NIST CSF domain and category.
Overview
A control enforced by an automated lock, a digital access log, and a camera pointed at the door showed the exact same status in Drata as one held together by a policy nobody had tested in a year: Ready. That was the only signal the system gave.
Enterprise compliance and security teams don’t manage a checklist. They manage a portfolio—dozens or hundreds of controls, wildly uneven in quality, wildly uneven in consequence—and they need the system to tell those two things apart. Not “is this done,” but “how good is it,” and “how much does it matter if it fails.”
That’s a different question than the one Drata was built to answer. Answering it meant designing two new concepts into the product: maturity and weight.
Roles & responsibilities
Customer/User Research, Customer Discovery & Synthesis, Information Architecture, Interaction Design, Prototyping, User Story Authorship, AI UX Strategy, Cross-functional Design Collaboration
Tools
FigJam/Figma for discovery collaboration, new components, and flows; ChatGPT for discovery partner; Notion to house documentation; v0 as a transitional prototyping too
The Primer: What Is Maturity? What Is Weight?
Control maturity is a method for scoring how reliable, optimized, and deeply embedded a control actually is—not whether it exists, but how well it’s managed over time. Frameworks like NIST CSF and CMMI build entire scoring models around this idea, because a checkbox doesn’t tell you whether a process will hold up under pressure.
Weight is a different question: how much does this specific control matter to the program. Two controls can be equally “not ready” and carry completely different consequences.
To make both concepts concrete: imagine an apartment building. Newman owns it. Jerry, Elaine, Cosmo, and George each rent a unit. Everyone shares the same requirement—restrict access to the building and to each apartment—and everyone uses some version of a lock to do it.
Maturity describes how that control is implemented and managed—not whether Jerry has a lock, but how much you can trust it to actually work, and how much evidence exists to prove it. The step from developing to mature isn’t just adding a camera—it’s replacing one shared code with credentials unique to each person, so a log actually counts as evidence: it proves who used the door, not just that someone did.
Weight is the other axis, and it isn’t always about the control itself—sometimes it’s about who’s exposed to it. The building has one shared risk: roof integrity. One shared control addresses it for everyone: scheduled roof inspections. Every tenant gets the exact same control, done the same way—identical maturity. But Jerry and Elaine live on the top floor, directly under the roof. Cosmo and George are two floors down. Score the weight out of five and the difference is concrete: a 5 for Jerry and Elaine, a 3 for Cosmo and George downstairs. Same risk, same control, same maturity—different weight, because the consequence of that roof failing isn’t the same for everyone under it.
Put together, maturity and weight answer the question compliance and security teams actually have: not “is this control done,” but “where should I be spending my attention and my budget.”
Customer research: two rounds, one clear signal
This was a PM-led research effort I joined partway through, after I shifted my focus into Controls—joint-owned from that point forward, not something I ran solo or was handed after the fact. Across two rounds of customer conversations, plus an ongoing thread of AI-feedback sessions and inbound field requests, one thing was consistent: almost nobody had a working system for this. The manual version of this work was resource-intensive enough that only the largest, best-staffed GRC teams could actually pull it off. Everyone else wanted it in the product for a plain reason: outside the product, it wasn’t something they could do at all.
The clear signal…
This wasn’t a feature preference. It was work customers already needed to do, with no way to do it at all outside the product.
One customer’s workaround was a homegrown dashboard.Only one customer had gone this far, but it’s the clearest data point in the research: a control assessment dashboard built outside Drata, complete with a “control weight” field, because the gap was already costing more than the build did.
Maturity models varied wildly, and nobody wanted to be forced into one. This was universal—no two customers in either round used the same approach. One ran a full NIST CSF sub-category model with target scores per domain (“we went from 30% compliance to 90%—this is what we got over the years”); others had no formal model at all, just a risk register in Google Sheets or a criticality flag bolted onto an Excel tracker.
Maturity, effectiveness, and risk stayed separate ideas customers wanted wired together. The clearest recurring ask in the research: three separate customers, independently, described some version of the same formula—residual risk = inherent risk (impact × likelihood) × control maturity/health—and nobody had one they trusted yet.
Customers reached for weight before maturity when triaging a control. One customer stated it as an explicit priority order—tie the control to its risk first, weight second, maturity last—but the instinct showed up any time weight and maturity came up together: know what’s at stake before asking how well something’s managed.
A maturity score only mattered if it told someone what to do next. This showed up in every conversation about scoring, just in different shapes. One customer’s version was a lightweight ROI model, combining the current-to-target gap with estimated cost and expected risk reduction per control to decide where the next security dollar should go.
The demand didn’t stay hypothetical. A single inbound field request, unprompted by any sales conversation, named two enterprise prospects asking directly for a “Controls Maturity concept”—and theirz described gap matched the research exactly: manual tagging today, no rollup, no built-in model.
Not every customer wanted this at all. The research explicitly tracked this split, not just observed it: customers who used weight and maturity today versus customers who didn’t. It concentrated in larger, more security-mature organizations—a real segment, not a universal need, and the design had to work for that segment without adding noise for everyone else.
Design strategy: mapping a process that didn’t exist yet
No GRC product on the market modeled this end-to-end. Where competitors touched maturity at all, it was a static tag on a control—not a program a team could actually run. There was no reference architecture to adapt, no “here’s how the category leader does it” shortcut. Before any screen got designed, the real work was mapping the lifecycle a compliance program actually moves through, from scratch.
I identified four stages in that lifecycle: Define & Configure, Assess, Plan & Prioritize, and Connection & Monitoring.
Define & Configure
Set target maturity and control weight at the org level, in bulk, by workspace, with sensible defaults by sub-function or domain—so an admin isn’t hand-configuring weight on hundreds of individual controls. Weight could also be driven by tags already in the system, like NIST function (“Identify,” “Protect”), instead of requiring a one-by-one setup pass.
Teams start from a template like NIST CSF, then tune the levels, criteria, rubric, and score thresholds to fit their program.
Classifying controls lets teams set targets and weights for whole groups at once, then adjust the few that matter most.
Assess
Define the scope—control category or domain, framework, business unit or entity, workspace—then run it. This is where the research-driven configuration questions live: who assesses, what gets assessed, how, and where (detailed below). A compliance manager chooses a rubric or scorecard template and a target maturity per sub-function to kick things off; Drata notifies control owners via tasks; owners answer, upload evidence, or flag gaps; the compliance manager reviews, can edit answers, collaborates with owners through notes, and finalizes. From there, Drata compares results against target maturity, weight, and risk to recommend which controls to prioritize—not just which are furthest from target, but what raising maturity on a given control would actually do for risk—surfaced as a point-in-time report and a maturity dashboard.
Scoping by domain shows which controls are included before the assessment goes out to control owners.
AI pre-assesses each criterion and shows its reasoning, so owners review and confirm instead of starting from a blank form.
Reviewers see responses, explanations, and internal notes in one place, and approving sets the control’s maturity level.
Plan & prioritize
Analysis becomes an action plan: per-control suggestions (“you need a policy,” “you should monitor this”), with start and end dates against the selected controls. That plan gets tracked, and the maturity dashboard reflects it as work happens
Every view compares current maturity to the targets set during setup, and recommendations reprioritize when teams change what matters.
Connection and monitoring
This is where an assessment’s results, and any change to a control’s data, reach outside of controls into the rest of the program. When a control’s maturity changes, notify the owners of any risks tied to that control—so a risk owner isn’t the last to know a control they depend on just got weaker or stronger.
Assess and Plan and Prioritize aren’t one-time events—a program runs assessments repeatedly, and each round feeds a fresh plan. None of the four stages run in a strict, one-way sequence either: a program might already have its risk connections wired up before its first assessment ever runs, while another might run assessments for months before anyone touches the risk side. The design had to hold up regardless of which door a customer walked in through.
Even the name for this end-to-end system was still an open question—Maturity Pathfinder, Planner, Navigator, and Management were all still on the table at this stage. That’s as good a signal as any of how early this was: the process got mapped before it had a name.
Mitigation formulas connect control maturity to risk scores, so improving a control lowers the risk it mitigates.
Configuring the assessment: where customers diverged
The “assess” stage carried the most research-driven variation, and broke into four configuration questions:
Who assesses the control? Either the control’s assigned owner does it directly, or the customer chooses specific assessor roles independent of ownership—several customers described a small central GRC team doing every assessment themselves, then reconciling differences as a group, regardless of who technically owned the control day-to-day.
What gets assessed? Either by metadata—assess every control matching a framework, domain, or classification in one pass—or hand-picked, for teams that wanted to scope an assessment narrowly. This choice mattered beyond convenience: assessing every control with no prioritization just rebuilds the same wall of manual effort this project existed to clear. Scoping by classification, domain, or framework let a team prioritize before starting, not sort it out after.
How does the assessment happen? Either directly against the maturity model’s criteria, or through a structured questionnaire that walks the assessor through it. The questionnaire path had its own fork: standard questions Drata could pre-populate (is there a policy, is there a risk mapped, is there continuous monitoring, is there an owner and reviewer) layered with room for model-specific nuance.
Where does it happen? Inside Drata directly, through an external-facing portal for people without full Drata access, or via a connection to wherever the customer already tracks this.
The harder design question sat inside “how”: once an assessment came back with answers, how does a maturity level actually get assigned? Three options surfaced:
Rubric tied to the responses
The most rigorous, and the least buildable—most customers’ criteria were qualitative and open-ended (“some personnel know how to perform the control,” “the control is performed, at least occasionally”), in a way that doesn’t map cleanly to a scoring formula.
Direct, manual selection
The simplest: an assessor reviews the responses and picks the level themselves, the way most customers were already doing it informally.
AI-assisted review
Sits in between: the assessor answers in their own words, and AI evaluates the response against the model to suggest a level, with the human confirming before it’s final.
Scope: ship the floor, not the ceiling
Once the model was designed, my instinct—and the team’s—was to build the whole thing at once: a fully configurable maturity model, a scoring rubric engine tied to it, and AI-assisted level assignment from free-text responses. It was the more impressive system, and the flow had already been designed to support it.
I checked that instinct against the research, and it didn’t hold up. Only one customer, at the time, had actually built a working scoring-rubric process—and it had taken them six weeks, run as a collaborative meeting series with control owners, to get through it. Everyone else was doing something flatter: a self-assessment questionnaire, a spreadsheet, a current-score-to-target-score comparison. Building a rubric engine for a pattern one customer had, while the rest of the market hadn’t asked for it yet, would have meant investing the hardest part of the system first against the thinnest evidence.
The call I helped the team land on: ship a flat criteria or questionnaire model for v1, with no scoring rubric required. Responses can be filled in manually or AI-assisted, with a human filling gaps and reviewing output—the same pattern Drata already used elsewhere. The maturity level gets assigned manually or via AI review of the response, not gated behind a rubric-building exercise most customers weren’t ready for.
What made this an easy call rather than a compromise: the flow doesn’t change shape if the rubric gets added later. A flat questionnaire goes out, gets answered, and gets a level assigned. Adding a scoring rubric later slots into the same “how should the level be selected” decision point—it doesn’t require rebuilding the assessment structure underneath it. We could re-index on how many customers actually wanted a full rubric process once there was more than one data point, without having over-built for a pattern that wasn’t broadly requested yet.
The same instinct applied at the program level, not just the assessment level. Rather than building the full connective tissue to Risk on day one, I worked with the team to scope this down to a crawl slice: maturity and weight as fields on the control, an aggregated operational dashboard to see them, and a data export for customers who wanted to build their own reporting. The formula work—connecting maturity and weight into an actual risk calculation—could come after the foundation existed to build it on.
We made the same call across all four stages, not just Assess. Configure’s slice got written up to bulk settings and tag-driven weight defaults instead of asking an admin to set target maturity and weight control-by-control—the harder, fully granular version of that stage never got proposed in the first place. Plan and Prioritize’s slice got written up to a flat action plan with dates, not the more ambitious automated remediation-routing the team could have designed instead. Connection and Monitoring’s slice got written up to a notification, not a formula. Four stages, four versions of the same decision: scope for what customers were already asking for, not what would look more impressive in a demo.
The scope itself didn’t hold still either. This project went through several rounds of rescoping over its life, mostly as a reaction to the org’s shifting push to have every proposed initiative lead with AI. Each round reshuffled which pieces made the cut, but the core call above—ship the flat, customer-validated version first—held through every pass.
Weight, risk, and the open architecture question
Weight’s real job was prioritization, but almost every customer conversation eventually pointed toward the same larger question: should weight and maturity feed directly into a risk score?
The demand was real and specific. Customers described wanting something close to residual risk = inherent risk (impact × likelihood) × control maturity/health, and at least one had already built an informal version of that math themselves, tying a control’s weight to a specific risk score’s movement.
Part of this got a real, sequenced answer. The “connection and monitoring” stage of the lifecycle scoped a narrow version for now: when a control’s maturity changes, notify the owners of any risk it’s tied to. No formula, no automated scoring—the right person finds out, full stop. A further-out idea, deliberately left unbuilt, was to let the system learn from what a risk owner does after that notification and suggest the same action automatically the next time a similar risk is affected, or eventually let maturity feed a risk’s inherent score directly. That’s the same shape as the scope call one section up: write up the notification now, earn the automation later.
What wasn’t resolved was the deeper architecture question underneath it. One line of thinking favored hard-coding maturity and weight as native fields with a built-in formula—faster to ship, easier to explain, but rigid the moment a customer’s definition of “residual risk” didn’t match Drata’s. The other favored a more general object-based custom-formula framework, where maturity and weight would just be two of many fields a customer could reference in their own formula, and where Risk—and potentially other objects—could plug into the same infrastructure rather than getting a one-off. That approach was more flexible and more defensible long-term, and also considerably more expensive to build first.
Some of that exploration got further than a whiteboard question. We looked at extending Drata’s existing risk-scoring formulas—already built to support custom mitigation rules—to accept a larger variable set that included maturity and weight directly, rather than standing up a parallel system from scratch.
This mirrors the tension the hierarchy work ran into with its own field-behavior presets: how much should the system decide for the customer versus hand them the primitives to decide for themselves. Unlike the notification staging above, this piece stayed genuinely open—the kind of question that needed more product runway than the roadmap ultimately gave it.
Signal
This work was deprioritized before shipping. The signal behind it came directly from customers, across two rounds of research:
A mid-market security company ran a full NIST CSF maturity model with target scores per sub-category, used it to justify multi-year security investment to leadership, and wanted a simple ROI calculation to decide where the next dollar of remediation budget should go.
An enterprise blockchain and fintech company was already trying to connect control quality to risk score manually, without a supported formula, and described control maturity as “very qualitative—what the assessor knows about the control.” They wanted Drata to give that judgment a structure.
A restaurant-technology platform had a clear, opinionated priority order for what they needed to see first—the risk connection, then weight, then maturity—and wanted monitoring scoped specifically to controls that were both high-weight and failing, not buried in a flat list.
A digital health company was managing weight and maturity informally in a spreadsheet-based risk register with no formal scoring system, and wanted a dashboard that surfaced their most under-invested, low-weighted controls first.
A vulnerability-management platform wasn’t using maturity yet at all—a six-person compliance team was still manually triaging control status—but their described pain (no rollup, no way to see where attention was needed across business units) was exactly what maturity and weight, aggregated, were built to solve.
Two enterprise prospects—one in healthcare, one in utilities—asked for a “Controls Maturity concept” by name through an inbound field request, unprompted by any sales conversation about this specific feature. Their described gap matched the research precisely: manual custom-field tagging today, no domain rollup, no built-in model.
The work wasn’t finished. The demand was already there, described the same way by customers who’d never talked to each other.
Beyond the Foundation
The signal pointed past what this project alone was built to solve. Enterprise GRC teams didn’t just want Drata to score their controls—they wanted it to become their continuous improvement flywheel, human judgment and AI working together to decide where a resource-strapped team should actually spend its next hour.
Discovery had already started on what that could look like beyond controls. A risk calculation, for instance, that set its own SLA based on a control’s combination of low maturity and high weight, instead of treating every control’s timeline the same way. Maturity and weight, once they existed as real fields, were the beginning of a network effect other parts of the product could eventually automate against.
