v3ndor.io

Security & Trust

Last updated: July 13, 2026

v3ndor.io is a vendor risk management platform. We hold customer data that is, by its nature, sensitive — vendor inventories, due diligence questionnaires, contracts, risk findings, and the people involved in remediating them. We treat that data accordingly.

This page is a public summary. Customers under NDA can request our full Trust Pack (penetration test letter, DPIA, network diagram) by emailing security@v3ndor.io. A SOC 2 report and a full BCP/DR plan are not yet available; ask and we will tell you where each stands.

1. Certifications & attestations

This table is the canonical statement of our compliance posture — where other v3ndor material describes a framework differently, this page governs. For our current attestation status against a specific framework, including SOC 2 and ISO/IEC 27001, or to request evidence under NDA, contact security@v3ndor.io.

2. Architecture & tenant isolation

• Cloud — Microsoft Azure, region East US 2. A geo-paired secondary region for disaster recovery is on our roadmap and not yet in production.
• Compute — Azure Container Apps running a Spring Boot application, fronted by Azure Front Door + WAF in Prevention mode. The origin is locked to Front Door two ways: the Container Apps ingress allow-lists only Azure Front Door’s backend egress ranges, and the application itself returns 403 to any request that does not carry the matching Front-Door-ID header (only the platform health probe is exempt). Front Door Private Link to a fully internal origin is configured for our next infrastructure tier and is not yet the live path.
• Data plane — Azure Database for PostgreSQL Flexible Server (VNet-integrated on a delegated subnet, public network access disabled) and Azure Storage Accounts (private endpoint, public network access disabled).
• Tenant isolation — single logical database, per-tenant Postgres Row-Level Security (RLS), enabled and forced on every tenant-scoped table that holds customer records, with a continuous-integration gate that fails the build if a migration adds such a table without RLS or enables RLS without FORCE. Application code sets a per-transaction SET LOCAL app.tenant_id (via set_config('app.tenant_id', …, true)) from the authenticated identity; the database engine enforces the boundary even if application code regresses.
• Network — the application reaches its database and its document storage over VNet integration and private endpoints inside an isolated Azure VNet; both have public network access disabled outright. Key Vault and our container registry are reached over their Azure endpoints and are protected by Entra ID managed-identity RBAC rather than by network isolation. Network security groups enforce deny-by-default inbound access.
• Secrets — Azure Key Vault, accessed via managed identity. No long-lived credentials in environment variables, container images, or source.

3. Data protection

Encryption in transit

• TLS 1.2+ enforced on all public endpoints. TLS 1.3 preferred. Older protocols and ciphers disabled at the WAF and ingress.
• HSTS, secure cookies, modern cipher suites only. Public certificates are Azure-managed (Microsoft) and rotate automatically.
• Internal traffic to the database and to object storage flows over private endpoints inside an isolated Azure VNet, and neither data plane has a public network path. Our secrets vault is reached over the same VNet but its data plane is not yet restricted to private access only; that hardening is on our roadmap.

Encryption at rest

• AES-256 on all customer data at rest — PostgreSQL (including automated backups) and Azure Storage (with infrastructure/double encryption).
• Encryption uses Azure platform-managed keys by default; our primary data stores additionally use customer-managed keys (CMK) held in Azure Key Vault, for independent key revocation and a key-usage audit trail. Per-tenant / bring-your-own-key (BYOK) isolation is not offered today — contact security@v3ndor.io to discuss Enterprise key-management needs.

Backups

• PostgreSQL automated backups with point-in-time restore (currently a 7-day retention window).
• Geo-redundant backups and cross-region failover are part of our production-hardening roadmap; ask under NDA for our current DR posture and target RPO/RTO.

Data residency

Production data is hosted in a single United States region — Azure East US 2. We do not offer a per-customer choice of hosting region today, and EU-only or UK-only residency is not yet available. If you have a hard data-locality requirement, raise it with security@v3ndor.io before you sign.

4. Access control & authentication

Customer access

• SSO — sign in with Microsoft Entra ID, Google, or your own tenant identity provider via OIDC. For SAML 2.0 single sign-on or SCIM 2.0 user provisioning, contact us — availability depends on your plan.
• MFA — passkey / WebAuthn (FIDO2) step-up verification on new-device sign-in and sensitive operations, enforced by the v3ndor application. Passkey enrolment is self-service per user. A tenant-wide “require MFA for every member” policy is on our roadmap and is not available today; customers who federate their own identity provider can enforce MFA there in the meantime.
• RBAC — least-privilege, workspace-scoped roles: tenant-admin (full workspace administration — members, roles, settings and destructive actions), user (baseline member) and vendor portal access, plus read-only external auditor access. Platform-operator (site-admin) privileges are never granted to customer accounts.
• Session management — SSO-backed session cookies (HttpOnly, Secure, SameSite=Strict). An idle session expires after 8 hours. An actively-used session is rolled forward so it does not expire mid-workday, but never beyond 7 days from the last interactive sign-in, after which a fresh sign-in is required. Users can revoke their own active sessions, and disabling a user immediately cuts off that user’s active sessions.
• API access — scoped tokens; rate-limited at the WAF; audit-logged.

Internal access

• All employees use Entra ID with phishing-resistant MFA (FIDO2 / WebAuthn).
• Platform-operator access is limited to a named allowlist held in deployment configuration. It can never originate from a customer identity provider, an invitation, or the in-product role editor, and there is no impersonation feature — our staff cannot sign in as one of your users.
• Operator actions against customer data are written to the tenant audit log.
• Staff access is granted and revoked through Entra ID. A formal joiner / mover / leaver checklist with retained revocation evidence is on our security roadmap; ask under NDA for our current internal access posture.

5. Secure development lifecycle

• Source control — GitHub with branch protection on main (enforced linear history, required status checks, no force-push or branch deletion), applied to administrators with no bypass actors.
• SAST — GitHub CodeQL (security-and-quality suite for JavaScript/TypeScript and Java) runs on every code-changing pull request, on every merge to main, and daily on a schedule; findings are triaged in GitHub Code Scanning.
• SCA — GitHub Dependency Review runs on every pull request and fails the check if a high-severity vulnerability would be introduced; Dependabot opens auto-fix PRs against the GitHub Advisory Database for npm, Maven, Docker, Terraform, and GitHub Actions ecosystems.
• Secrets scanning — GitHub Secret Scanning + push protection (server-side block at git push) with AI detection, non-provider patterns, and validity checks for known-format credentials.
• IaC scanning — Checkov scans every Terraform change and reports findings into GitHub Code Scanning (advisory rather than blocking); Conftest is the blocking gate, denying any plan that would leave a data plane publicly reachable; Hadolint covers Dockerfile hygiene.
• SBOM — a CycloneDX SBOM is generated automatically on dependency changes and daily against main; container images built for tagged releases additionally carry a BuildKit SBOM + provenance attestation on the image manifest.
• Container hardening — distroless nonroot runtime image (uid 65532); no shell or package manager; base images pinned by SHA digest.
• Change control — every change reaches main through a pull request that must pass the required automated checks; direct pushes are blocked with no bypass actors. Peer review by a second engineer is not yet a required gate — we are a small team and the automated checks carry that weight today.
• Training — secure-coding training annually for all engineers; OWASP Top 10 + CWE Top 25 reviewed at onboarding.

6. Logging & monitoring

• Application and infrastructure logs — including Azure platform audit events such as Key Vault access and the subscription Activity Log — are centralised in Azure Monitor / Log Analytics.
• The in-product tenant audit log (who did what, when, against which record) is held in the application database under row-level security and is append-only. It is readable by every member of the workspace, including read-only external auditor sessions; vendor-portal users cannot see it.
• Azure Monitor alerts cover availability, server error rate, latency, container crash-loops, Front Door WAF block spikes, and control-plane changes that should not happen quietly — Defender plan changes, network security-group edits, Key Vault deletion and Azure Policy changes. Alerts reach the on-call engineer around the clock.

7. Vulnerability management

• Patching SLAs (from disclosure / availability of fix):
  • Critical — within 48 hours
  • High — within 7 days
  • Medium — within 30 days
  • Low — within 90 days
• External penetration test — annually by an independent third party. Summary letter available under NDA.
• Coordinated disclosure — we do not run a paid bug-bounty programme today. We do operate a safe-harbour disclosure policy and credit reporters by default; see Vulnerability disclosure below.
• Image scanning — every container image is scanned for CVEs at build time and continuously in registry.

8. Incident response

• Documented incident response plan, severity matrix, and escalation paths.
• S1 incidents reach our on-call engineer around the clock. Alerts are delivered by email today; a multi-person rotation backed by a dedicated paging service is on our roadmap and not yet in production.
• Customer notification: in the event of a security incident affecting customer data, we will notify affected customers without undue delay and in any case within the timeframe specified in the DPA (default 72 hours of confirmation).
• Post-incident reviews are documented; root-cause analysis and corrective actions are shared with affected customers under NDA.
• A formal tabletop-exercise programme with a documented exercise log is on our roadmap and not yet established.

9. Business continuity & disaster recovery

• RTO (recovery time objective): 4 hours for full-region disaster recovery.
• RPO (recovery point objective): 1 hour — continuous write-ahead-log backup with point-in-time restore on Azure Database for PostgreSQL.
• Single-region deployment in Azure East US 2. Zone-redundant compute and database high availability, and a geo-paired secondary region for DR, are part of our production-hardening roadmap and are not yet enabled, so the objectives above are targets rather than a contracted commitment until they land.
• A formal DR drill programme with a documented BCP test log is on our roadmap and not yet in production; our current backup and point-in-time-restore configuration is available for review under NDA.

10. Vendor & sub-processor management

• All sub-processors, and every third-party service our platform contacts at runtime, are listed at /legal/subprocessors.
• Each is reviewed for security, privacy, and contractual posture before onboarding (we eat our own dog food).
• 30 days' advance notice of new or replacement sub-processors via the sub-processor page and email subscription.
• Contractual flow-down: each sub-processor is bound by a written agreement with confidentiality and security obligations no less protective than those we owe customers.

11. Privacy controls

• Data minimisation — we only collect what we need to deliver the service.
• Data subject requests — customers can self-serve export their records (CSV from every list view, plus a downloadable audit-log package) and permanently close/delete their workspace from Settings. An Export my data dossier returns the records referencing the signed-in user across every workspace they belong to. Anything beyond that is fulfilled by our team on request. End-user requests should be routed via the customer (controller). Email privacy@v3ndor.io.
• Standard Contractual Clauses (SCCs) are in place for transfers from the EEA / UK / Switzerland to the United States, where applicable. Transfer impact assessment available under NDA.
• No training of third-party AI models on customer data. Any AI features that may process customer data are listed in the sub-processor list and are subject to no-train commitments.

12. Vulnerability disclosure

We welcome reports from security researchers. If you believe you have found a security vulnerability in v3ndor.io, please email security@v3ndor.io with:

• A description of the issue and its impact.
• Steps to reproduce (a proof-of-concept if possible).
• Your name / handle for credit (optional — we credit by default unless you ask us not to).

Safe harbor

We will not pursue legal action against researchers who:

• Make a good-faith effort to avoid privacy violations, destruction of data, and interruption of service.
• Only interact with accounts they own or have explicit permission to test.
• Do not exfiltrate customer data or pivot beyond the minimum needed to demonstrate the issue.
• Give us reasonable time to remediate before any public disclosure (we target 90 days; happy to coordinate longer for hard issues).

Out of scope

• Denial-of-service attacks against production.
• Social engineering of staff or customers.
• Physical attacks against offices or data centers.
• Findings from automated scanners without a working proof-of-concept.
• Missing "best-practice" headers without a demonstrable impact.

PGP

We do not publish a standing PGP key. For sensitive reports, request a per-incident key at security@v3ndor.io and we will supply it along with its fingerprint.

13. Contact

• Security disclosures & trust pack requests — security@v3ndor.io
• Privacy / data subject requests — privacy@v3ndor.io
• Sub-processor change notifications — subscribe at /legal/subprocessors