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 across dozens or hundreds of controls.
This 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 wasn't just inefficient — it 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, shifting from a fragmented model to 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, not just a feature — 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. This shift changed the system from:
Control-centric → 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 but fundamental shift: 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 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.
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 hybrid model allowed us to introduce structure without breaking existing workflows.
Evidence architecture — dual-model system balancing platform-wide reuse with local flexibility
Existing functionality of uploading individual pieces of evidence to a control — renamed to miscellaneous evidence.
Flow shows user uploading a piece of evidence relevant to a single control from the control details drawer.
Adding evidence to Evidence Library and linking multiple controls to it.
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.
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.
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 a critical gap: 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 — ticket status is reflected 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 — rather than fragmented — required careful thinking around system relationships and information architecture.
Early on, I explored more complex approaches to tracking changes, but research showed that what customers actually needed was much simpler: a clear, reliable history 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. That shift — from trying to solve everything upfront to designing for evolution — is something I've carried into subsequent projects.