From doc to decision: how lean risk teams scale reviews
Privacy and security teams are leaner than ever, and the problems in front of them keep getting harder — AI most of all. In that environment it is very easy to fall behind on risk reviews.
Fall far enough behind and you are left with two options, both bad.
You become the department of no. You slow the business down and deprive it of the fuel it needs to grow and innovate. Or you accept risks you are not comfortable with, because the business has to move and someone has to let it.
There is a third option. We call it doc to decision, and it is built for lean, fast teams who want to scale: to conduct reviews with the rigor they expect while moving faster with the business rather than against it.
Why build a risk platform around risk reduction instead of compliance?
Because compliance follows from reducing risk, not the other way around.
TerraTrue is a risk management platform purpose-built for privacy, security, and AI risks. A lot of risk platforms focus on the compliance checkbox and the documentation exercise. We took a different approach and focused on risk reduction: meaningfully equipping privacy and security teams to reduce the risk in everything the business is doing, whether that is product feature launches, internal tools, vendors, marketing campaigns, or data sharing.
Compliance and documentation matter a great deal. We just think of them as a byproduct of the risk reduction work. Get the risk reduction right and the other things happen on their own.
That approach shapes three things we care about offering customers.
Proactive. Bring privacy and security teams in earlier in the development process, when their feedback is still actionable, so they can work with the business in lockstep instead of slowing it down. The worst time to start a review is usually the day before the product is due to launch.
Business-friendly. The business shouldn't think of privacy and security as a burden or a tax. It should be easy, it should be graceful, and it should foster collaboration across teams. The question is always how to remove as many obstacles to adoption as possible.
Scalable. In today's world this matters more than ever, and it is where a lot of the energy goes: how do we help customers scale their risk program rather than just run it?
What is doc to decision?
It is an effort to streamline the risk process end to end by tackling every stage of a review and making each one fast, consistent, and as automated as possible.
The point is to let you conduct reviews at higher scale, which in turn helps the business, because now they are faster to launch and innovate.
It breaks into the three big stages of any review process:
- Discoverability. Knowing the work exists
- Triage. Deciding what deserves your attention
- Assessment and reporting. Completing the work and recording the findings
Here is what changes at each one.
Stage one: how do you find out about work early enough to matter?
By connecting to the document where the work is first written down.
TerraTrue already supports a large number of integrations meant to bring work into the platform automatically, from wherever teams are doing that work. Jira is one of the most popular, a rich integration that pulls in ongoing development activity and launches a review process for each item.
But a ticket is not the earliest signal available. Every day where the review hasn't started while the business is moving forward is a day lost, and it is very hard to make up for.
So the question became: how do we get in even earlier, before a Jira ticket is filed?
That led to document systems. When a product or feature is being designed, the product and engineering team writes a design doc. That design doc then feeds the UI and UX designs, the technical specs, and the other work that follows. But it always starts with a design document.
Tapping directly into document systems does two things. It meets developers where they already work, and it starts the review when the design doc is written, potentially days or weeks before a ticket is set up and the work is scheduled.
Both integrations are live today: Notion and Google Docs. Launching a review through them is deliberately trivial. In Notion the developer checks a checkbox. In Google Docs they apply a label and set its status to Ready.
We've written more about how the Google Docs trigger works, from the label to the AI-answered intake workflow.
From there TerraTrue knows the document needs review, receives it from your document system, and analyzes it. Then it comes back to the developer with immediate feedback.
Most of the time that feedback is: you're good to go. No human in the loop, no review needed, the feature isn't introducing significant risks, so proceed.
Less often it is: wait a minute, this is particularly sensitive, and the review is going to take longer. Either way the developer knows immediately and can plan for it. No surprises, and no waiting weeks just to find out whether a review is needed and how long it will take.
Stage two: how do you decide which reviews actually deserve your time?
By automating the analysis that reviewers currently do by hand before they can even make that call.
Privacy and security teams get overwhelmed by the volume coming at them from the business. Realistically they have time to review only a few of the many reviews arriving at once. The hard part is determining which ones need the work and which don't meet the risk bar.
That sounds simple. It isn't. Making the determination means analyzing what the document is about, how it ties into previous work, and what can be inferred about the risks being introduced. All of that takes time, effort, and energy before any actual reviewing happens.
The goal is to give the reviewer immediate, actionable feedback about the risks present or absent in a document, along with a risk severity rating, enough to either close the review as not needed or flag it for closer attention.
Four kinds of signal feed that rating.
Taxonomy. What types of data are used in this feature, what they're used for, what the effort is trying to achieve, and how you intend to use the data you collect. Out of the box, TerraTrue maps these to risk ratings across privacy, security, and AI regulations around the world. It's also configurable: if you disagree with a rating, you can say this matters more to us, and we use that signal when assigning risk.
Novel versus iterative. Is this the first time the company has done this, or is it another turn on something existing? The two get treated differently. Novel work deserves holistic rigor and a search for areas to investigate more deeply. Iterative work — performance refactoring, expansion into a new geography — narrows the review or eliminates it. So you get both a risk rating and a sense of scope.
Regulatory lens. If a feature involves children's data, or transfers data to a region you consider high risk, that automatically dictates certain assessments and a level of scrutiny. You get told that up front, so you can decide how to proceed.
Contextual intelligence. This is the part a dedicated review tool can do that a general one can't. We have the whole history of reviews your organization has done, which means we can tell what is genuinely novel about the current work versus what you've already looked at, approved, and allowed. We can also see how it connects to assessments you may need: a new DPIA or LIA, updates to your ROPA tables. If novel work is needed, a review is warranted. If your library already covers it and nothing needs to change, you can fast forward.
All of that gets surfaced to the reviewer as summary and context, so the decision about how to proceed is quick.
Stage three: how do you get through the assessments faster?
By pre-populating them from what the review already knows.
Once a review has been triaged and worked, the assessments follow: a DPIA, an LIA, a transfer assessment, whatever the work calls for. This is generally a complex and daunting task involving a lot of forms.
TerraTrue speeds it up by pre-populating as much as possible from what it understands about the launch, so you aren't spending time re-deriving questions, considerations, and trade-offs that the review already surfaced. The side benefit is consistency: assessments drawn from the same underlying context look alike across reviews.
What this adds up to
Three stages, each accelerated. More understanding of what the business is doing at any moment, without the dread, because the things that don't warrant your time get filtered out before they reach you.
This is what scaling looks like in practice. Jam City, one of the largest mobile gaming companies in the world, runs its privacy, security, and vendor risk programs on a lean central team. On TerraTrue, they complete 10x more reviews than before, and each review runs at least 10x deeper — here's how Jam City did it.
Running a risk program is complex and challenging, and underneath it is a decision every team eventually makes: are you an engine of growth for your business, or a giant tax on it?
Teams are lean. The goal is to help you build the right privacy and security posture in your organization without overburdening yourself, your team, or the business.
Frequently asked questions
What does doc to decision mean?
It refers to shortening the path between the moment work is written down in a document and the moment a risk decision is made about it. Rather than waiting for a ticket or a manual intake form, the review starts from the design doc itself and moves through triage and assessment with as much of the analysis automated as possible.
Does every document trigger a full review?
No. Most documents come back with immediate feedback that no review is needed, because the work isn't introducing significant risk. The value is in filtering, so reviewers spend their time on the smaller set of work that actually warrants it.
How is a document trigger different from a ticket trigger?
Timing. A ticket is filed after the design thinking is done. A design doc is written while it's still happening, which can be days or weeks earlier — early enough that reviewer feedback can still change the design rather than just flag problems with it.
What happens to work that has been reviewed before?
It gets recognized. Because the platform holds the history of your organization's reviews, it can distinguish genuinely novel work from another iteration of something already approved, and narrow or skip the review accordingly.
Which document systems does this work with?
Notion and Google Docs today, each with a one-step trigger: a checkbox in Notion, a label in Google Docs. The Google Drive integration is available now and can be enabled from your integration settings.
To turn this on for your team, see the Google Drive integration guide. For the reasoning behind document-triggered reviews, read why risk reviews should start in the doc, not the ticket.
