Skip to Content
Who can use this
Available to
DeveloperAdministrator
Not available to
Governance EngineerCompliance OfficerBusiness OwnerAuditor

SDK Quick Start — GRC, ESG & Enterprise Risk Management

Getting started: GRC, ESG & Enterprise Risk Management

This guide takes you from install to your first attributed governance record in grc, esg & enterprise risk management. You will install the SDK, configure a provider, instrument a workflow step with the real OTel attribute vocabulary from this vertical, and have a reviewable evidence record in your portal within an afternoon. There is no scaffolding project — just your API key and the three steps below.

Why this matters right now. As of March 2026, agentic AI in GRC, ESG, and enterprise risk management is deployed across: automated risk assessment and risk register maintenance (ISO 31000 / COSO ERM), continuous control monitoring and automated evidence collection (NIST SP 800-53, SOX 404), AI-driven regulatory horizon scanning and obligation mapping, AI governance maturity assessment and gap analysis (ISO/IEC 42001, NIST AI RMF), third-party AI vendor risk evaluation and due diligence, AI model risk management under SR 11-7 (model inventory, validation, performance monitoring), ESG data collection, materiality assessment, and disclosure preparation (CSRD, ISSB, SEC Climate Rule), internal audit AI (AI-assisted audit planning, continuous transaction monitoring, anomaly detection), AI incident and near-miss reporting (EU AI Act Article 62, DORA), board-level AI governance reporting and dashboard generation, and enterprise AI programme governance (Chief AI Officer enablement, AI use case inventory under OMB M-24-10). ISO/IEC 42001:2023 is the emerging certification standard for AI management systems — analogous to ISO 27001 for information security — and is driving significant GRC platform investment in 2025–2026. The EU AI Act Article 9 risk management system requirement and Article 17 quality management system requirement are the most operationally demanding regulatory obligations for providers of high-risk AI, applying from August 2026. ISO/IEC 42001:2023 is the first certifiable AI Management System standard. It requires organisations to establish context, define AI policy, conduct AI risk assessments, implement controls from Annex A, and undergo third-party certification audits. Several EU member state regulators and the EU AI Office are signalling that ISO 42001 certification may satisfy (or substantially support) the EU AI Act Article 17 quality management system requirements for providers of high-risk AI. The EU AI Act Article 62 serious incident reporting obligation requires providers to report serious incidents (death, serious harm, fundamental rights violations) to market surveillance authorities without undue delay — AI GRC platforms must build automated incident classification and regulatory notification workflows. DORA Article 28 requires EU financial entities to maintain a register of all ICT service providers, including AI vendors — AI GRC portals are the natural home for this register. SR 11-7 model risk management guidance, while US banking-focused, has become the de facto global standard for AI model governance in financial services and is increasingly applied by non-financial regulators by analogy.

How the layering works

You are not adopting a separate product surface for this vertical. You are adding a market-specific vocabulary layer on top of the same core session model used everywhere in VeriProof.

LayerWhat you configureWhat changes downstream
Core SDKAPI key, application identity, session lifecycle, export path, base governance metadataThe same trace, evidence, and export foundation used across every implementation
GRC, ESG & Enterprise Risk ManagementOTel attributes, permitted values, and workflow metadata drawn from this vertical catalogPortal evidence records, policy inputs, and exports become standards-literate for this market
Review surfacesRules, evidence packages, and internal reviewer workflowsThe same labels and values appear without translation during review or audit

If you need the cross-industry baseline first, open the core SDK reference, Python core, or .NET core before continuing here.

Step 1 — Install

TypeScript / Node.js

npm install @veriproof/sdk-core

Python

pip install veriproof-sdk

.NET

dotnet add package Veriproof.Sdk

Step 2 — Configure

Call the configuration helper once, before any AI framework initialises. After that call, every OTel span in the process — whether emitted by your code or by a framework adapter — is exported automatically to VeriProof.

Your API key comes from the VeriProof portal. Try a live demo to see the portal before you register, or start a free Builder account and use the environment variable pattern above directly.

Need a production credential path rather than sandbox exploration? Get API access for a Builder account, or contact the team if you need an architecture or compliance review alongside implementation.

Step 3 — Instrument your workflow

The governance vocabulary for this vertical lives in the GRC, ESG & Enterprise Risk Management reference. Use the OTel attribute names below — they are the same names the portal uses in evidence records and the same names your policy engine will evaluate. Consistency here is the point.

OTel attributeSample valueCategory
grc.risk.assessment_methodqualitativeRiskAssessmentMethod
grc.risk.treatment_strategyavoidRiskTreatmentStrategy
grc.risk.appetite_statuswithin_appetiteRiskAppetiteStatus
grc.compliance.action_statusopen_not_startedComplianceActionStatus
grc.nist_ai_rmf.functionGOVERNNISTAIRMFFunction
grc.nist_ai_rmf.implementation_tiertier_1_partialNISTAIRMFImplementationTier

TypeScript example

import { configureVeriproof, VeriproofClient, VeriproofSdkOptions, SessionMetadata } from '@veriproof/sdk-core';
import { RiskAssessmentMethod, RiskAssessmentMethodMeta, RiskTreatmentStrategy, RiskTreatmentStrategyMeta } from '@veriproof/sdk-core/verticals/grc-esg-enterprise-risk';

// Call once at application startup
configureVeriproof(
  VeriproofSdkOptions.createProduction({
    apiKey: process.env.VERIPROOF_API_KEY!,
    applicationId: 'grc-esg-enterprise-risk-app',
  }),
  { serviceName: 'grc-esg-enterprise-risk-app', setGlobal: true },
);

// Instrument a governed workflow
const client = new VeriproofClient(
  VeriproofSdkOptions.createProduction({ apiKey: process.env.VERIPROOF_API_KEY! }),
);

const session = client
  .startSession('grc.esg.enterprise.risk.review')
  .withSessionMetadata(SessionMetadata.forTransaction('txn-001').withEnvironment('production'))
  .addStep('evaluate', { output: { status: 'completed' } })
  .withMetadata(RiskAssessmentMethodMeta.otelAttribute, RiskAssessmentMethod.qualitative)
  .withMetadata(RiskTreatmentStrategyMeta.otelAttribute, RiskTreatmentStrategy.avoid)

await session.complete();

Python example

import os
from opentelemetry import trace
from veriproof_sdk import VeriproofClientOptions, configure_veriproof
from veriproof_sdk.verticals import grc_esg_enterprise_risk as geer

# Call once at application startup
configure_veriproof(
    VeriproofClientOptions(
        api_key=os.environ["VERIPROOF_API_KEY"],
        application_id="grc-esg-enterprise-risk-app",
    ),
    service_name="grc-esg-enterprise-risk-app",
    set_global=True,
)

tracer = trace.get_tracer(__name__)

# Instrument a governed workflow
with tracer.start_as_current_span("grc_esg_enterprise_risk.review") as span:
    span.set_attribute(geer.RiskAssessmentMethod.__otel_attribute__, geer.RiskAssessmentMethod.qualitative.value)
    span.set_attribute(geer.RiskTreatmentStrategy.__otel_attribute__, geer.RiskTreatmentStrategy.avoid.value)
    span.set_attribute(geer.RiskAppetiteStatus.__otel_attribute__, geer.RiskAppetiteStatus.within_appetite.value)
    ...

.NET example

using Veriproof.Sdk;
using Veriproof.Sdk.Core.OpenTelemetry.Verticals.GrcEsgEnterpriseRisk;

// Configure once at application startup
builder.Services.AddVeriproof(options =>
{
    options.ApiKey = builder.Configuration["VERIPROOF_API_KEY"]!;
    options.ApplicationId = "grc-esg-enterprise-risk-app";
});

// Instrument a governed workflow step
using var activity = ActivitySource.StartActivity("evaluate");
    activity?.SetTag(RiskAssessmentMethod.Metadata.OtelAttribute, RiskAssessmentMethod.qualitative);
    activity?.SetTag(RiskTreatmentStrategy.Metadata.OtelAttribute, RiskTreatmentStrategy.avoid);
    activity?.SetTag(RiskAppetiteStatus.Metadata.OtelAttribute, RiskAppetiteStatus.within_appetite);

How teams use this in production

  • Enterprise Risk Assessment & Treatment: Risk Assessment Method. AI GRC agent selects risk assessment method based on risk category and materiality. Tier 4 critical AI systems require at minimum 'red_team_exercise' and 'threat_modeling_stride'. OPA policy enforces that any new high-risk AI deployment must have a completed risk assessment with a documented method before receiving production ATO. (Eu AI Act Art9: EU AI Act Article 9 — High-risk AI risk management system requires documented risk identification and evaluation; the chosen risk assessment method must be recorded and reproducible)
  • Enterprise Risk Assessment & Treatment: Risk Treatment Strategy. AI risk agent assigns a treatment strategy to each identified risk. OPA policy blocks 'accept_retain' treatment for any AI risk rated above the board-approved risk appetite threshold without explicit Risk Committee or CRO HITL authorisation. (Eu AI Act Art9: EU AI Act Article 9(3) — Risk management system must include residual risk evaluation; 'accept_retain' for any risk classified as high requires documented AO or Risk Committee approval)
  • Enterprise Risk Assessment & Treatment: Risk Appetite Status. AI risk monitoring agent continuously recalculates risk scores. 'Exceeds_tolerance' status on any material risk triggers immediate CIRO/CRO HITL notification and initiates the board escalation workflow. AI agent cannot autonomously resolve an 'exceeds_tolerance' status — only the Risk Committee can. (Coso Erm 2017: COSO ERM 2017 Principle 6 — Board defines risk oversight and appetite; 'exceeds_tolerance' requires board notification)
  • Enterprise Risk Assessment & Treatment: Compliance Action Status. AI compliance agent tracks all open remediation actions against their deadlines. 'Overdue' items trigger management escalation. OPA policy enforces that 'escalated_to_regulator' and 'regulatory_breach_confirmed' status transitions require CCO and General Counsel HITL — AI cannot self-escalate to regulatory authorities. (Eu AI Act Art62: EU AI Act Article 62 — Serious incident reporting: 'escalated_to_regulator' status for AI serious incidents must be filed without undue delay)

Next steps

Ready to connect your first workflow?

Register a free Builder account — 500 tamper-proof Proofs per month, full SDK and REST API access, and your first evidence record in the portal before you leave your desk.

Live demo →Start free →

Last updated on