Compliance workflows rely on evidence; documentation that demonstrates security controls are operating effectively. To meet frameworks such as SOC 2, ISO 27001, and HIPAA, organizations must provide supporting documentation across dozens or hundreds of controls.
In Drata, this evidence was historically managed at the control level, where artifacts were uploaded and maintained independently separately across all controls, which created a structural problem:
- The same evidence often applied to multiple controls and every update required manually tracking down and replacing each instance
- Updates required manual duplication across every instance
- Teams had no reliable way to ensure consistency across their compliance posture
As customers scaled to larger frameworks and audits, this model became increasingly fragile. Evidence management was inefficient and introduced risk.
"When I upload the same evidence to more than one control, I have to remember all the places I put it and replace it everywhere."
This project was an opportunity to redefine how evidence is represented and managed across the platform to transform Drata's evidence model into a reusable system.
I led the design of Evidence Library across multiple phases, working closely with product and engineering to evolve both the data model and the user experience over time.
- Redefined the evidence model across the platform — Enabled evidence to be created once and applied across multiple controls, reducing duplication and ensuring consistency across compliance requirements.
- Established a foundation for long-term evidence management — Introduced versioning and audit-aware behaviors that allow teams to maintain historical records while updating evidence over time.
- Extended the system beyond static documentation — Designed integrations that convert operational work (tickets) into compliance evidence, connecting external ticketing providers into the evidence lifecycle.
- Shaped a platform capability — Evidence Library became a core system used across compliance workflows, influencing how evidence is generated, maintained, and audited across the product.
We moved to a new model where evidence exists independently and can be linked across controls, changing the system from control-centric to evidence-centric.
The shift from a fragmented, control-level model to a centralized, reusable evidence system
The initial version of Evidence Library introduced a simple change: Evidence is no longer tied to a single control, it becomes a reusable entity across the system. Instead of attaching documents independently within each control, users could store evidence once and link it across multiple controls. This change introduced a dual-model system combining reusable evidence with control-specific evidence to balance structure and flexibility:
Reusable evidence (system-level)
Evidence is created and stored in Evidence Library, then linked across multiple controls. Updates propagate automatically, ensuring consistency across the system.
Flow shows user uploading a single piece of evidence to Evidence Library, linking it to multiple controls, and then confirming it being reflected in the control details drawer.
Control-specific evidence (local flexibility)
Users can still attach evidence directly to a control when needed for ad-hoc documentation or control-specific context. This existing functionality was renamed to miscellaneous evidence.
Flow shows user uploading a piece of evidence relevant to a single control from the control details drawer.
This hybrid model allowed us to introduce structure without breaking existing workflows.
Evidence architecture — dual-model system balancing platform-wide reuse with local flexibility
Bi-directional workflows
A key consideration was that not all users work from the same entry point. While some personas (e.g. compliance managers) operate from Evidence Library, others (e.g. control owners) primarily work within controls. The system needed to support both, so we introduced a bi-directional workflow between controls and Evidence Library:
- Users can link existing evidence from Evidence Library directly within a control
- Users can also create new evidence from a control and add it to Evidence Library
To support this, the system surfaces when a similar or existing piece of evidence already exists, helping prevent duplication and encouraging reuse.
Flow shows user linking a previously uploaded piece of evidence to Evidence Library, to a single control from the control details drawer.
System highlights duplicates when creating new evidence from the control and adding it to Evidence Library.
While the initial problem was clear and we had numerous insights and quotes from customers to release a v1, post-launch research focused on understanding how evidence behaves over time.
We ran moderated sessions exploring:
- How users update evidence
- How they expect history to be preserved
- How evidence should behave during audits
This research directly informed versioning behavior, audit-aware downloads, and system expectations for historical accuracy.
Iteration 1 — Designing for change over time
Compliance evidence is not static, it evolves. After launching v1, research revealed that users needed to update evidence without losing historical context. This led to the introduction of versioning as a core system behavior.
Versioning system
- New evidence replaces outdated versions without deleting history
- Previous versions remain accessible for audit and record-keeping
- Audit downloads include both current and historical evidence when relevant
This transformed Evidence Library from a storage system into a time-aware system aligned with audit workflows. The system interprets the customer's audit period to surface only relevant evidence, pulling from both current and historical versions while restricting access from auditors to out-of-scope files.
Flow shows user updating an evidence past its renewal date, impacting all linked controls and showing how the previous version is stored under version history.
Iteration 2 — Extending the system beyond documents
Once the core model was established, the next opportunity was reducing manual documentation work. Compliance teams were already tracking work in tools like Jira, Asana, and ServiceNow, but still had to manually replicate that work in Drata. We extended Evidence Library to support ticket-based evidence generation.
Ticketing integration workflow
- Users provide a ticket URL
- Drata retrieves structured ticket data
- The ticket is converted into an evidence record to reflect its status in the platform
- The evidence can be linked to controls and included in audits
This connected operational systems directly into the compliance workflow, reducing duplication and improving traceability.
Adding a Jira ticket as new evidence and previewing the ticket details once evidence is saved.
Evidence Library saw strong adoption across the platform, with 72% of customers activating the feature and 41% integrating it into their ongoing compliance workflows, representing thousands of customers using the system in production.
- Reduced manual duplication and update effort — Evidence can be created once and reused across controls, eliminating the need to track and update the same document in multiple places
- Improved consistency and audit readiness — Versioning and centralized evidence management ensure documentation remains accurate, traceable, and defensible over time
- Expanded evidence beyond static documents — Ticketing integrations enabled operational work to be captured as evidence, reducing manual documentation and improving traceability
- Established a foundation for future automation — The structured evidence model enables further automation across compliance workflows, including integrations and AI-assisted features
This project challenged me to think beyond individual features and design for a system that works across multiple entry points, personas, and workflows.
One of the most complex aspects was balancing structure with flexibility. Evidence could be created and managed from different parts of the product, depending on the user's role, and ensuring those experiences felt connected required deep understanding of our users' mental models and our platform capabilities, thinking carefully around system relationships and information architecture.
Early on, I explored more complex approaches to tracking changes and version history, but research showed that customers needed a simpler and clearer process to just keep a log of their evidence. Shifting to a straightforward version log made the system easier to understand while still meeting audit requirements.
This project also reinforced the importance of early cross-functional alignment. Evidence touches multiple areas of the product: controls, audits, and integrations, and collaborating closely with those teams early on was critical to ensuring the system worked cohesively across the platform.
Finally, one of the most important decisions was knowing when to ship. We focused on validating the core model enough to release a V1, then used real customer usage to iterate and refine the system over time. Delivering value incrementally to learn from our users is something I've carried into subsequent projects.