Planned for the MVP
Pillar for OneTrust.
What we’re building: evidence by service, mapped to the controls in your OneTrust library.
System of record
GRC holds the program. Pillar supplies the proof.
GRC software often holds the system of record for a business continuity and disaster recovery program: the services, their owners, the obligations, the controls, the plans. What it cannot see is what is actually running underneath, or whether it recovered last night. Pillar supplies that, by service, as an evidence layer.
OneTrust
What OneTrust holds.
- Frameworks and the control library, SOX to ISO 22301.
- Control implementations per asset, with owners and effectiveness.
- Evidence tasks with a collection cadence and a due date.
- Assets, vendors and entities, and the links between them.
- Risks and issues, routed to their owners.
- Assessments and their approvals.
Pillar
What Pillar adds.
- A service record discovered without agents, credentialed over WinRM.
- The application record: components, dependencies, the backup policy inherited.
- Evidence dated per verification, from the provider that ran it.
- Estimated recovery per service, against the commitment.
- Drift as a change to the service, before the next collection is due.
- Kept current through change, by external id.
Where it lands
Each Pillar record has a home in OneTrust.
Built on OneTrust’s public API. Pillar writes; OneTrust stays the system of record.
In Pillar
Service record
- Payroll · Dana Reyes, HR
- Tier 1 · critical · Support: HR Applications
- 15 minute RTO · 15 minute RPO
- Quarterly DR exercise · Runbook: yes
In OneTrust
Asset
An asset in the Inventory API, created and kept current by external id, with owner, department, criticality, RTO and RPO as attributes on the asset.
POST /api/inventory/v2/inventories/assetsPUT /api/inventory/v2/inventories/assets/external-id
In Pillar
Application record
- HRS-APP01 → HRS-DB01, DC01, DNS02
- Active Directory · SQL Server · DNS
- Backup jobs, retention and restore points inherited
- Application group with a proposed boot order
In OneTrust
Linked assets and a control implementation
Each component an asset, linked to the service by a typed relationship; the service’s control implementation ties it to the controls it must satisfy, with the evidence attached.
GET /api/inventory/v2/inventories/{id}/relations/assetsGET /api/controls/v1/control-implementations/{id}
In Pillar
Evidence record
- Payroll application · 01 Sep 2026 · Evidenced
- SOX · Recovery within the stated objective
- DORA · Backup and restore, exercised
- ISO 22301 · Continuity exercised and evaluated
In OneTrust
Evidence task implementation
OneTrust’s own evidence object: a collection cadence, a last-collected date and a status, taking files, notes and links. It links to the control implementation, and through it to the control and its framework.
GET /api/controls/v1/evidence-task-implementations/{id}POST /api/controls/v1/control-implementations/{id}/attachments
Mapped to the controls
From a verification to the framework that asks for it.
Every piece of evidence Pillar writes travels OneTrust’s own chain to the control library.
Evidence
Dated, from the provider that ran it
Evidence task
Collected on its cadence
Control implementation
On the service’s asset
Control
Identifier and clause
Framework
SOX · GDPR · DORA · HIPAA · ISO 22301
In the product
Send to OneTrust.
From the evidence view, one action beside PDF and CSV.
How it connects
Built on OneTrust’s public API.
OAuth 2.0 client credentials
A client credential you create in OneTrust; Pillar holds the token and nothing else.
Kept current by external id
Every record carries Pillar’s id, so a change updates the asset rather than duplicating it.
Well inside the limits
A full estate is a fraction of OneTrust’s hourly allowance, so the evidence stays fresh without crowding your other integrations.