Trust & Controls

One Control Library, Every Framework Mapped To It

Fintra ships a canonical library of about 90 controls across roughly 30 domains. Each control carries its evidence and policy requirements and maps to every framework that needs it - so you collect a piece of evidence once and it counts everywhere.

Talk to usFree to start - no card required.
Fintra · Control Library
CANONICAL CONTROLS
90
across ~30 domains
FRAMEWORKS MAPPED
7 seeded
SOC 2 · ISO · HIPAA · PCI · GDPR · CCPA · CSF
REUSE FACTOR
1 : many
one control, many frameworks
AC-2 - Access provisioning & reviewMaps to 6 frameworks
CR-1 - Encryption at rest & in transitMaps to 7 frameworks
GV-3 - Management review cadence1 evidence stale
AI-1 - Governed-action decisioningStreaming

Illustrative product view

What a control library is (and why one canonical set matters)

A control library is the master list of the safeguards your organization commits to operate - access reviews, encryption, change management, incident response, vendor due diligence, and so on. The problem most teams hit is that every framework restates the same underlying safeguards in its own language, so they end up maintaining a separate spreadsheet per framework and re-collecting the same evidence several times.

Fintra takes the opposite approach: one canonical control is the unit of truth, and frameworks are mappings onto it. When an auditor asks for encryption evidence, it is the same control and the same artifact whether the report is SOC 2, ISO 27001, or HIPAA.

The domains the library covers

DomainExample controlsFrameworks that draw on it
Identity & AccessProvisioning, MFA, least privilege, access reviewsSOC 2, ISO 27001, HIPAA, PCI DSS
Encryption & DataAt-rest / in-transit encryption, key management, retentionAll seven seeded frameworks
Logging & MonitoringAudit logs, anomaly detection, alertingSOC 2 CC7, PCI Req 10, NIST CSF Detect
Change ManagementReviewed, tested, approved changesSOC 2 CC8, ISO A.8, PCI Req 6
Vendor & Third PartySecurity reviews, DPAs, tieringISO A.5, GDPR Art. 28, SOC 2
Governance & PolicyPolicy set, roles, management reviewNIST CSF Govern, ISO A.5, SOC 2 CC1
Representative control domains and what lives in each

How cross-framework mapping saves the re-collection tax

Collect once, satisfy many

  1. 1

    Pick a control

    Take a canonical control such as "user access is reviewed quarterly with evidence of who reviewed and when."

  2. 2

    See every framework it satisfies

    The mapping shows the control answers SOC 2 CC6, ISO 27001 A.5.18, HIPAA access management, and PCI Requirement 7 at once.

  3. 3

    Attach evidence once

    Upload or auto-collect the review artifact against the control, not against each framework.

  4. 4

    Add a framework later for free

    When a new framework is scoped, the controls it shares are already evidenced; you only chase the genuine delta.

What is seeded vs. what you map to

  • Seeded (audit-ready baseline): SOC 2, ISO 27001, NIST CSF, HIPAA, PCI DSS, GDPR, CCPA - controls, evidence requirements, and policy stubs pre-populated.
  • Map-to / prepare-for: other frameworks (HITRUST, ISO 42001, NIST AI RMF, EU AI Act, FedRAMP, CMMC, and more) reuse the same canonical controls, but we never call them certified or turnkey.
  • The library is the substrate the whole platform stands on: monitoring, evidence coverage, and the auditor view all read control status from here.

Frequently asked questions

How many controls are in the library, and across how many domains?

Roughly 90 canonical controls across about 30 domains - identity and access, encryption, logging, change management, vendor risk, governance, and more. Each control carries the evidence items and policy stub it needs, so you start from a populated baseline rather than authoring controls from scratch.

Which frameworks are actually seeded versus mapped?

SOC 2, ISO 27001, NIST CSF, HIPAA, PCI DSS, GDPR, and CCPA are seeded - their control, evidence, and policy requirements ship pre-mapped, so you are audit-ready by default on the baseline. Other frameworks reuse the same canonical controls on a map-to / prepare-for basis; Fintra never issues certifications.

How does one control library reduce audit work?

Because frameworks are mappings onto shared controls, evidence collected for a control satisfies every framework mapped to it. You stop maintaining a spreadsheet per framework and stop re-collecting the same artifact, so adding a framework later mostly means evidencing the delta.

Does this replace my auditor or assessor?

No. Fintra is the control, policy, and evidence layer that keeps your program continuously audit-ready and cuts preparation from weeks to days. The audit, certification, or attestation itself is still performed by an independent, qualified auditor, assessor, or authorizing body - Fintra never issues certifications.

Stay in the loop

One practical finance briefing a week - new guides, checklists, and benchmarks.

 

Start from a real control baseline

Map every framework to one canonical library and collect evidence once, not many times.

Talk to us