v3ndor.io

Security & Trust

Last updated: October 16, 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

• Hosting — v3ndor.io runs on Microsoft Azure, with customer data hosted in the United States.
• Edge protection — all traffic passes through a managed edge network that filters malicious requests before they reach the application, and the application refuses traffic that bypasses it.
• Tenant isolation — every customer’s records are isolated from every other customer’s, and the boundary is enforced by the database itself, not only by application code. An automated check on every change fails the build if new customer data could be stored outside that boundary.
• Network — customer data stores have no public network access, and inbound access is denied by default.
• Secrets — held in a managed secrets vault and accessed by workload identity. No long-lived credentials in configuration, images, or source.

3. Data protection

Encryption in transit

• TLS 1.2 or higher enforced on every public endpoint, with older protocols and ciphers disabled.
• HSTS and secure cookies. Public certificates are managed and rotate automatically.
• Traffic between the application and customer data stores stays on private network paths.

Encryption at rest

• AES-256 on all customer data at rest, including backups and stored documents.
• Encryption keys are managed by v3ndor.io. Customer-managed or per-tenant keys (BYOK) are not offered today — contact security@v3ndor.io to discuss Enterprise key-management needs.

Backups

• Customer data is backed up automatically, and backups are encrypted.
• Backups and our current disaster-recovery posture are described in more detail under NDA.

Data residency

Customer data is hosted in the United States. We do not offer a per-customer choice of hosting location 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

• Sign-in — sign in with your Google or Microsoft work account today. Single sign-on through your own identity provider (SAML or OIDC) and SCIM user provisioning are available on request — contact us to enable them for your workspace.
• MFA — passkey step-up verification on new-device sign-in and sensitive operations, with self-service passkey enrolment per user. Workspace admins can require MFA for every member of the workspace.
• 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 privileges are never granted to customer accounts.
• Session management — idle sessions expire, and every session requires a fresh sign-in periodically. Users can revoke their own active sessions, and disabling a user immediately cuts off that user’s active sessions.
• API access — scoped tokens, protected against abuse, and audit-logged.

Internal access

• All employees use phishing-resistant MFA.
• Platform-operator access is limited to a short, named list of staff. 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 centrally through our identity provider. 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 — protected main branch: required automated checks, no force-push or deletion, and no bypass for administrators.
• Static analysis — security-focused static analysis runs on every code change, on every merge, and daily; findings are triaged.
• Dependency scanning — every change is checked for known-vulnerable dependencies and fails if it would introduce a high-severity one; automated pull requests keep dependencies patched.
• Secrets scanning — commits are scanned for credentials, and a push that contains one is blocked.
• Infrastructure checks — infrastructure changes are policy-checked, and a change that would expose a customer data store to the public internet is blocked.
• SBOM — a software bill of materials is generated automatically, and release images carry build provenance.
• Hardened runtime — minimal runtime images that run as a non-root user, with no shell or package manager, built from pinned base images.
• Change control — every change reaches production through a pull request that must pass the required automated checks; direct pushes are blocked. 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, infrastructure and cloud-platform audit events, including access to secrets, are centralised and retained.
• The in-product audit log (who did what, when, against which record) is append-only and isolated per customer like every other record. It is readable by every member of the workspace, including read-only external auditor sessions; vendor-portal users cannot see it.
• Automated alerts cover availability, error rates, latency, blocked-attack spikes, and security-relevant configuration changes that should not happen quietly. 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 release image is scanned for known vulnerabilities at build time and continuously afterwards.

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

• Customer data is backed up automatically and can be restored after an outage or data loss.
• The service runs from one hosting location in the United States today. Higher-availability hosting and recovery to a second location are on our roadmap and are not yet enabled.
• A formal disaster-recovery test programme is on our roadmap. Our recovery objectives and current backup configuration are 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