Snapshot 17467
Normalized text
Scripts and page chrome removed; this is what change detection compares.
Trust Center sections
DiligenceVDR is built for financial professionals handling sensitive M&A, fundraising, and due diligence materials. Compute and document storage run in two regions — Virginia (us-east4) for US projects and Netherlands (europe-west4) for EU projects — selected at project creation. The data plane (documents, folders, audit log, permissions) stays in the chosen region. The control plane (user accounts, project index, billing) is US-hosted and covered by the EU-U.S. Data Privacy Framework. Regional API endpoints are exposed at us-api.diligencevdr.ai and eu-api.diligencevdr.ai so customers can verify routing.
CIS Controls v8.1 IG1 — self-attested April 2026
CSA STAR Level 1 — registry-listed April 2026 ( CAIQ v4.1.0 )
CSA AI Controls Matrix v1.0.2 — AI-CAIQ self-assessed April 2026
Per-project data residency — compute, database, and storage in US (Virginia) or EU (Netherlands), selected at project creation
AES-256 at rest, TLS 1.2+ in transit, per-project DEKs wrapped by per-region Google Cloud KMS
AI processing opt-out — zero document content sent externally when disabled
GDPR-compliant Processor with customer-signable DPA
EU-U.S. and Swiss-U.S. Data Privacy Framework — self-certified (record B-07967)
Responsible disclosure via security.txt (RFC 9116)
Certifications & Frameworks
Our compliance posture is anchored by completed CIS IG1, NIST SSDF, CSA STAR Level 1, and CSA AI-CAIQ self-attestations, alignment with NIST CSF 2.0, and active participation in the EU-U.S. and Swiss-U.S. Data Privacy Frameworks, with SOC 2, ISO/IEC 27001, and ISO/IEC 42001 (AI Management System) readiness programs active.
CIS Controls v8.1 — Implementation Group 1
Self-attested April 21, 2026
All 56 IG1 safeguards implemented. Full evidence package maintained (policies, training attestations, asset inventory, vendor reviews). Annual re-attestation; quarterly evidence refresh.
NIST Secure Software Development Framework (SSDF)
Self-attested April 21, 2026
Self-attested per NIST SP 800-218 v1.1 via the CISA Secure Software Development Attestation Form (OMB M-22-18 / M-23-16). Practice coverage spans PO (Prepare Organization), PS (Protect Software), PW (Produce Well-Secured Software), and RV (Respond to Vulnerabilities). Signed by Co-Founder Michael Pierce, CTO. Signed attestation and supporting practice mapping available under NDA — request via .
CSA STAR Level 1 (Self-Assessment)
Registry-listed April 27, 2026
Listed on the Cloud Security Alliance STAR Registry under the Consensus Assessments Initiative Questionnaire (CAIQ) v4.1.0, mapped to the Cloud Controls Matrix (CCM) v4. Annual renewal cadence. Submitted as DiligenceVDR, LLC.
CSA AI Controls Matrix v1.0.2 (AI-CAIQ Self-Assessment)
Self-assessed April 27, 2026
Full AI-CAIQ v1.0.2 self-assessment completed against the Cloud Security Alliance's AI Controls Matrix v1.0.2 (released October 2025) — 313 questions across 18 domains including the AI-specific Model Security domain. Our role is AI deployer/user of managed Vertex AI foundation models, so Model Security controls related to training pipelines, model checkpoint signing, and model serialization are documented as inherited from Google Cloud Vertex AI under the Google Cloud DPA. Annual review cadence aligned with the AIMS. Completed questionnaire available under NDA — request via .
NIST Cybersecurity Framework 2.0 (CSF 2.0)
Aligned April 23, 2026
Aligned with NIST Cybersecurity Framework 2.0 (CSWP 29). Current-state Organizational Profile covers all six Functions across 106 subcategories with cofounder concurrence. Implementation tiers range from Tier 2 (Risk Informed) to Tier 3 (Repeatable). Reviewed quarterly. Profile available under NDA — request via .
SOC 2 Type II
Readiness program active
Policy set, control mapping, and evidence collection in place. Auditor engagement planned. CIS IG1 evidence forms the SOC 2 foundation.
ISO/IEC 27001:2022
Readiness program active
Scope, Statement of Applicability, and Annex A control mapping complete.
ISO/IEC 42001:2023 (AI Management System)
Readiness program active
AIMS scope, AI policy, AI Impact Assessment (ISO/IEC 42005-aligned), and Annex A Statement of Applicability complete. Our role is AI deployer/user of managed Vertex AI foundation models (Google Gemini); we do not train or fine-tune models. AI risk treatment aligned with ISO/IEC 23894. Customer-controlled AI opt-out per project. AIMS document available under NDA — request via .
Ongoing Oversight
Active
Beyond one-time attestations, our compliance program operates on recurring cadences: quarterly internal review of security controls with founder concurrence; regular platform-access reviews; annual vendor reviews of Critical and High tier sub-processors; annual CSA STAR Level 1 renewal; formal incident-response and breach-notification workflows; and active subscriptions to threat-intelligence feeds. A live compliance Plan of Actions & Milestones (POA&M) is maintained and available under NDA on request.
GDPR (EU 2016/679)
Compliant as Processor
DPO appointed. EU data residency available per project. Customer-signable DPA available on request. International transfers from the EU and Switzerland are covered by our DPF self-certification (below), with EU SCCs available as a complementary mechanism.
EU-U.S. & Swiss-U.S. Data Privacy Framework
Self-certified — record B-07967
DiligenceVDR, LLC is self-certified with the U.S. Department of Commerce for the EU-U.S. DPF and the Swiss-U.S. DPF and adheres to the DPF Principles for personal data received from the European Union and Switzerland. The Federal Trade Commission has jurisdiction over our DPF compliance. Unresolved complaints are subject to the EU DPAs panel (EU-U.S. DPF) and the Swiss FDPIC (Swiss-U.S. DPF), with binding arbitration available under DPF Annex I. Public listing: dataprivacyframework.gov . Full notice in the Privacy Policy .
Infrastructure
Compute, database, and storage are provisioned per project in either US (Virginia, us-east4) or EU (Netherlands, europe-west4). A project's data plane stays in its chosen region; the shared control plane (accounts, project index, billing) is US-hosted under the EU-U.S. Data Privacy Framework.
Compute
Railway — US or EU
API, background jobs, document processing. US (us-east4) or EU (europe-west4) per project.
Database
Google Cloud SQL (PostgreSQL) — US or EU
Project and document metadata. EU projects' data plane stays in europe-west4; the shared control plane is US-hosted.
File Storage
Cloudflare R2 — EU or US
Document files, encrypted at rest. Region selected per project.
Email
Resend — EU region
Invitation and notification emails
AI Processing
Google Cloud Vertex AI — EU or US
Processing stays within the project's geography (EU or US)
Error Monitoring
Sentry — EU region
ingest.de.sentry.io endpoint
Frontend
Railway — US or EU
Next.js web application. One deployment serves both regions via host-based routing; no customer document data stored.
Encryption
Document content is encrypted at rest, in transit, and at the application layer. Document, folder, and project names stay plaintext so they remain searchable; their confidentiality is protected by the database's at-rest encryption, project-scoped Row-Level Security, and the authentication layer rather than column-level cipher.
At rest
AES-256 on R2 objects, Google Cloud SQL (PostgreSQL 18) with Google-managed keys, and all provider-managed backups. Sensitive document content (chat messages, extracted text chunks, AI-derived summaries) is additionally encrypted at the application layer with a per-project Data Encryption Key (AES-256-GCM), which is itself wrapped by a per-region Google Cloud KMS key (see Envelope encryption below). Document, folder, and project names are intentionally not column-encrypted — they need to stay searchable and indexable, and rely on the database's at-rest encryption, Row-Level Security, and authentication for confidentiality.
In transit
TLS 1.2+ on all external connections, with TLS termination at Cloudflare's edge in Full (Strict) mode and validated certificates on every origin. HSTS is enforced with a one-year max-age, includeSubDomains, and preload — diligencevdr.ai is listed on Chrome's HSTS preload, so browsers refuse to connect over HTTP even on first visit. Internal service-to-service traffic runs on Railway's private network with no public ingress to the database, cache, sidecar, or malware scanner.
Document downloads
≤5-minute R2 presigned URLs signed server-side by the Rust sidecar. Plaintext decryption keys never reach the browser.
Envelope encryption
A two-tier envelope model, live in production. Each per-project DEK is wrapped by a per-region Google Cloud KMS key (us-east4 for US projects, europe-west4 for EU) with automatic rotation. The key material stays in the room's own region — an EU project's DEK is wrapped by an EU-resident key and never leaves the EU. Because a DEK can only be unwrapped with live, audited, revocable KMS access in-region, a database or storage compromise alone cannot decrypt customer documents.
Customer-managed keys (BYOK) — roadmap
Planned for institutional and deal-room-tier customers: supply your own KMS key (Google Cloud KMS first) to wrap your organization's DEKs, retaining the ability to revoke or destroy it to terminate our access. Not yet generally available.
Chain of Custody
Every document is fingerprinted at ingest and re-verified on a schedule so tampering, bitrot, or accidental overwrite cannot go undetected. The fingerprint and every action against the document are anchored in a tamper-evident audit log with a SHA-256 hash chain that you can verify independently.
Plaintext fingerprint at ingest
The first authoritative server-side read computes a SHA-256 over the decrypted plaintext and stores it on the document. The digest is included in the upload audit event so the chain-of-custody anchor is fixed before any processing or transformation runs.
Periodic integrity verification
An hourly sweep re-hashes batches of documents and compares the result against the digest captured at ingest. A clean match emits a document.integrity_verified audit event so the log carries proof that we actively check, not just that we noticed when something broke.
Mismatch alerting
Any divergence raises a document.integrity_mismatch event in the tamper-chained audit log and immediately notifies our security contact. The runbook quarantines the document, restores from object-storage versioning where available, and verifies the audit chain hasn't itself been tampered with.
Independent verification
The fingerprint is exposed on the document Details panel with a copy button. A counterparty who holds the original file can hash it locally and confirm it matches what we ingested — no privileged access required.
Forensic standards
The pattern is informed by ISO/IEC 27037 (digital evidence handling) and NIST SP 800-86 (forensic integrity), which call for cryptographic hashes at acquisition and at every transfer. We are not certified against either standard; we follow the practice because it's the right shape for due-diligence chain-of-custody, not because we hold an attestation.
AI Processing
Projects can opt out of ALL AI functionality. When disabled, zero document content is sent to any external AI provider.
DiligenceVDR uses Google Cloud Vertex AI for document extraction, vector embeddings, and AI-powered search. All models are Google Gemini, served via Vertex AI: the project's primary chat model with a secondary Gemini model as an in-geography fallback when the primary is degraded. Everything runs on Google's infrastructure under the Google Cloud DPA, so Google remains the sole sub-processor for AI processing. Processing stays within your project's geography — EU project data is processed entirely within the EU, US project data within the US. Document content never leaves its geography: EU data remains in the EU (under the Google Cloud DPA with Standard Contractual Clauses), US data remains in the US. * Projects can opt out of all AI features — in that mode no document content is sent to Google or any external AI provider. Search is powered by native document extraction and PostgreSQL full-text search — fully private, with zero external API calls.
* Document translation is the one exception, and only for larger Office files. Office files (DOCX, PPTX, XLSX) above roughly 50,000 characters of text are translated by DeepL, which currently processes in the EU (Cologne, Germany) regardless of project region — so a US project's larger Office-file translations transit the EU under Standard Contractual Clauses until DeepL US-region processing is enabled. Smaller Office files — the majority in a typical room — are translated by Microsoft Azure AI Translator in the project's own region (West Europe or East US), so they follow the project's geography like everything else. PDF translation (Google Cloud Translation) and all other AI processing follow the project's geography.
AI access is gated at three layers and resolves on every request:
Project-level surface toggles
Beyond the master AI opt-out, each project independently controls two surfaces: the in-app Ask AI chat (used inside the VDR UI) and external MCP (lets a customer connect Claude Desktop, ChatGPT, or another MCP-compatible client). A project can enable in-app chat while keeping external MCP off, or vice-versa, or neither.
Group-level capability grants
Within an AI-enabled project, only groups explicitly granted the chat_access or mcp_access capability can use those surfaces. The default is no grant — admins opt groups in deliberately, and grants can be bulk-cleared in one click from project settings.
Per-folder scope follows the user's tier
When a user invokes AI (chat or MCP), the AI sees exactly what that user can see in the web UI — no more, no less. Read operations require view tier; write operations require manage tier. There is no separate per-folder AI permission to keep in sync — the existing folder ACL ladder is the only source of truth.
Geographic data residency
AI processing stays within your project's geography — EU project data is processed entirely within the EU (GDPR-compliant, under Standard Contractual Clauses), US project data within the US. Chat, document extraction, and PDF translation run on Google's EU or US multi-region endpoints; embeddings and the secondary fallback model run on same-region endpoints. The one exception is translation of LARGER Office files: DeepL processes DOCX/PPTX/XLSX above roughly 50,000 characters in the EU regardless of project region, so a US project's larger Office translations transit the EU under Standard Contractual Clauses until DeepL US-region processing is enabled. Smaller Office files — the majority in a typical room — go to Microsoft Azure AI Translator in the project's own region and do not leave it. Otherwise EU data never leaves the EU and US data never leaves the US.
Google Cloud Data Processing Addendum
Google processes data under their Cloud DPA with EU Standard Contractual Clauses (SCCs). All AI runs on Google Vertex AI under that single DPA — Google is the sole contractual sub-processor for the AI processing we initiate (extraction, embeddings, in-app chat); no separate AI-vendor agreement applies.
External MCP transmits to the connecting client's AI provider
Enabling external MCP additionally lets document content a user requests through a connected client (e.g. Anthropic Claude, OpenAI ChatGPT) reach that client's AI provider — a tool the customer's own user connects, distinct from our Google Vertex AI sub-processor. A project admin acknowledges this disclosure once, when AI processing is first enabled for the project; the acknowledgment is recorded with a timestamped snapshot of the disclosed providers, after which external MCP can be turned on without a separate prompt. In-app Ask AI never uses an external client — it runs on Google Vertex AI only.
Data minimisation
Only extracted text content from uploaded documents is sent to Vertex AI — never the original files, user metadata, or deal identifiers.
No training on your data
Vertex AI API usage under Google Cloud terms does not permit your data to be used for model training. This applies to every Gemini model in the pipeline.
Engagement Analytics & Access Logging
For projects you own, DiligenceVDR records document engagement — which documents participants open, active viewing time, and media playback progress — so administrators can see how counterparties are working through the room. For security and access auditing, we also log the IP address each document is opened from — the same forensic posture as document downloads. Our lawful basis is the project owner's legitimate interest in a defensible audit trail, not consent; what is collected is disclosed in our privacy policy before any participant accesses a room. We collect the least viewer data needed for that purpose.
Always-on access logging
The IP address each document is opened from is logged for security and access auditing — captured on open (never on every page scroll or media event), the same forensic posture as document downloads. There is no separate toggle: a defensible record of who accessed what, and from where, is part of what a data room provides.
Session-security monitoring, not fingerprinting
Each audited action also records standard connection metadata: the browser's user-agent string and the coarse, city-level location our CDN derives from the connecting IP. Automated sweeps check this for signs of account misuse — a session active from two places no traveler could connect, several distinct devices on one login at once, or scripted bulk downloading — and alert our security team. We do not use covert browser fingerprinting (canvas, audio, font probing) or behavioral biometrics, and no precise geolocation is ever collected.
Document-level, not per-page
Engagement is measured as active viewing time at the document level. We do not build per-page heatmaps. Active time is bounded per session so a tab left open does not inflate the number.
Admin-only visibility
Engagement data and viewer IPs are visible only to the project's administrators. Other participants in the room cannot see who opened what.
Region-resident
Engagement events and viewer IPs are stored in the project's own region. EU project data stays in the EU; US project data stays in the US — same residency posture as the documents themselves.
24-month retention, erasable on request
Engagement data and viewer IPs are retained for up to 24 months from the event, then deleted. A viewer's IP is erased ahead of that window if they exercise their right to erasure — the aggregate access record is retained, but the IP itself is nulled.
Print: best-effort logging + real control
When someone opens the print dialog on a document in our viewer, we record a best-effort 'Print attempted' event with their IP, visible to admins in Reports → Document Access. It's an attempt, not proof of a printout — the browser never reveals whether they printed, cancelled, or saved as PDF — and printing a downloaded file from the operating system, or taking a screenshot, can't be observed by any web application. So we also control printing where it's enforceable: reviewer groups can be served permission-locked PDFs that cannot be printed, copied, or edited, and every downloadable copy is watermarked with the recipient and timestamp, so a printed leak still traces back to a person.
Excluded from billing
This viewer activity is never used for metering or billing. Billing is computed exclusively from document inventory (storage and normalised page counts); viewer events live in a separate data plane and do not feed the billing pipeline.
Sub-processors
Third-party services that process customer data on our behalf. For each provider we disclose the category of service, the purpose of the disclosure, the categories of data accessed, the hosting region, and the data processing agreement.
All sub-processors below are contractually bound as Service Providers (CCPA/CPRA) or Processors (GDPR and comprehensive U.S. state privacy laws — see the Privacy Policy for the full 19-state scope). Their DPAs prohibit use of customer data for their own purposes or for any purpose other than providing services to DiligenceVDR.
Region tag legend: DPF means the provider is itself self-certified to the EU-U.S. and/or Swiss-U.S. Data Privacy Framework, in addition to DiligenceVDR's own DPF certification (record B-07967). SCCs means transfers rely on EU Standard Contractual Clauses (Module 2) under the provider's DPA.
Provider Category Purpose Data accessed Region DPA
Cloudflare R2 Object storage Stores encrypted customer document files uploaded to data rooms Document files (encrypted at rest) EU or US (per project; DPF) View →
Railway Cloud hosting & compute Runs the web frontend, API, background workers, and document-processing jobs that serve customer traffic. Two regional stacks: US (us-east4, Virginia) and EU (europe-west4, Netherlands). Document content (in-memory during processing), account identifiers US-East and EU-West (DPF) View →
Railway Managed cache & queue Hosts the Redis cache and Sidekiq job queue per region (US and EU). No customer document content is stored in Redis; only ephemeral job metadata and session keys. Job metadata, session keys US-East and EU-West (DPF) View →
Google Cloud SQL (PostgreSQL) Managed database Hosts the PostgreSQL databases that store project metadata, permissions, and audit logs. Three instances: control plane (US-East, shared) for user accounts and project index; US data plane (US-East) for US projects' room data; EU data plane (EU-West, Netherlands) for EU projects' room data. EU projects' document metadata and audit logs never leave europe-west4. Account identifiers, document metadata, audit logs US-East and EU-West (DPF) View →
WorkOS Authentication & identity Sign-in, enterprise SSO/SAML, directory sync, and multi-factor authentication Email, name, session tokens US (SCCs) View →
Google Cloud (Vertex AI & Cloud Translation) AI / LLM provider (optional per project) Vertex AI: document text extraction, vector embeddings, semantic search, chat-based Q&A, and the terminal text fallback for any translation the document engines cannot complete. Cloud Translation: translation of PDF documents when a project user requests it, and failover for Word/Excel/PowerPoint files when the primary engine cannot complete them. Both only when AI features are enabled by the project administrator Extracted document text (AI features); PDF document files, and Office files on failover (translation, in-flight only — not used for training under Google Cloud terms) EU or US (per project; DPF) View →
Resend Transactional email Delivers invitation, notification, and security emails to account holders Name, email address EU region (DPF) View →
Sentry Error monitoring Collects application error telemetry to diagnose service failures Error logs (document content scrubbed) EU region (DPF) View →
Better Stack Log management Centralized application log management — aggregates server logs from the API, workers, sidecar, and web for operational diagnostics and alerting Application logs (operational; no document content — PII minimized at the source) EU region (DPF + SCCs) View →
Stripe Payments Processes billing and subscription payments for paid plans Billing contact, billing address, card token (PCI-scoped to Stripe) US (DPF) View →
DeepL Document translation (optional per project) Translates uploaded Word/Excel/PowerPoint files when a project user requests translation — the primary engine for files above roughly 50,000 characters of text, and the quality fallback for smaller ones if Azure cannot complete them. DeepL never receives PDFs: its PDF pipeline would introduce a further document-conversion sub-processor, so PDFs stay with Google Office document files (in-flight only; deleted by DeepL after translation per Pro/API no-data-retention; we are on the Growth tier — no training on customer data) EU (DeepL SE, Cologne, Germany — EU data centers) Pending
Microsoft Azure AI Translator Document translation (optional per project) Translates uploaded documents when a project user requests translation: data and text formats (CSV, TSV, TXT, HTML, Markdown, Outlook MSG, OpenDocument spreadsheets), images (JPEG, PNG, BMP, WebP — translated via OCR), and Word/Excel/PowerPoint files under roughly 50,000 characters of text, which is the majority of Office documents in a typical room. Larger Office files go to DeepL first. Azure never receives PDFs Document files (in-flight only; No-Trace — Azure does not persist or log document content, and does not use it for training) EU or US (per project; West Europe / East US resources; DPF) View →
ConvertAPI Document conversion / rendering (optional per project) Converts CAD drawings (.dwg/.dxf) and Apple Numbers spreadsheets to viewable PDFs when such files are uploaded. Routed to the regional endpoint matching the project's residency (EU projects → EU endpoint, US projects → US endpoint), so document bytes stay in-region Document files (in-flight only; converted in memory with StoreFile=false — zero retention on ConvertAPI's servers) EU or US (per project; regional endpoints) View →
Document metadata hygiene
Most data rooms serve uploaded files with original metadata intact. Author names, edit history, embedded GPS coordinates, and DMS attribution travel from the seller's laptop to the bidder's hard drive. DiligenceVDR strips this metadata server-side during processing, so what bidders download is the file without the leak vectors that come standard everywhere else. Coverage is per format — the table below states exactly what is removed from each, and where nothing is.
One exclusion worth naming: the pre-2007 binary Office formats (.doc, .xls, .ppt) are not scrubbed. Their metadata lives in OLE2 compound streams that our tooling can read but cannot rewrite, so those files are served exactly as uploaded. The modern equivalents (.docx, .xlsx, .pptx) are scrubbed normally, and re-saving a legacy file in the modern format before upload brings it into coverage.
Scrubbing fails open: if a particular file resists processing, the original is served and the seller is notified. Access is never blocked on a hygiene failure. Digitally signed files (PDF and Office) are detected and preserved unmodified to keep signatures valid.
Format What we strip What we preserve When we skip
PDF /Info dict, XMP metadata stream Page content, AcroForm fields, annotations, embedded fonts, ICC color profile Digitally signed PDFs (signature preserved)
Office (DOCX/PPTX/XLSX) docProps/{core,app,custom}.xml (author, company, lastModifiedBy, etc.), embedded thumbnails Document body, comments, tracked changes, customXml content, slide notes Files with an /_xmlsignatures part (signature preserved)
Legacy Office (.doc/.xls/.ppt) None — not supported Entire file, including SummaryInformation and DocumentSummaryInformation streams Always — no writer exists for OLE2 metadata streams
Images (JPEG/PNG/HEIC/TIFF/WebP/GIF) EXIF, GPS coordinates, XMP, IPTC, embedded thumbnail Pixel data (byte-exact), image dimensions Unsupported formats
Audio (MP3/M4A/WAV/FLAC) ID3v1/v2 tags, M4A iTunes atoms, container metadata Audio stream (byte-exact), cover art Never (always applied)
Video (MP4/MOV/MKV) Container metadata atoms, encoder tags, MP4 udta GPS Video stream, audio stream (byte-exact), chapter markers, subtitle streams Never (always applied)
Project administrators can disable metadata scrubbing per project in Project Settings → General for the rare case where byte-exact original files are required (signed contracts, files where author attribution is intentional). Disabling is audit-logged.
Your Choices
You have several ways to limit how your personal information is used or disclosed:
Disclosure to third-party controllers. We do not disclose personal information to any third party acting as an independent controller. If this changes, we will provide advance notice and an opportunity to opt out.
AI / LLM processing. AI features are off by default at the project level. Project administrators may enable or disable AI processing at any time; when disabled, no document content is sent to any external AI provider.
Access, correction, export, deletion. Use the self-service controls in Profile → Privacy or email .
Transactional email. Account-critical notifications (security alerts, invitations, access changes) cannot be disabled because they are required to operate the Service. We do not send marketing email derived from account data.
For the full list of rights and how to exercise them, see our Privacy Policy → Your Choices .
Data Protection Officer
Michael Pierce
Data Protection Officer
For data subject requests (access, erasure, portability), you can also use the self-service tools on your profile page.
Responsible Disclosure
Report a suspected vulnerability to . We acknowledge reports within two business days. Please do not publicly disclose until we've had a reasonable window to remediate. We do not currently operate a paid bug-bounty program.
Machine-readable contact per RFC 9116: security.txt .
Security Overview (NDA)
A full Security Overview — covering controls, architecture, incident response, BCP/DR, and subprocessor attestations — is available under NDA for prospective and current customers evaluating DiligenceVDR for sensitive transactions.
Request a copy: