Security

In transit. All traffic between your browser and VendorLockbox is encrypted with TLS 1.2 or higher. HTTP requests are automatically upgraded to HTTPS.

At rest. Encryption at rest is planned for our Azure deployment, where application data and uploaded documents will sit on Azure managed disks - these apply industry-standard AES-256 encryption with platform-managed keys by default. That environment is still being provisioned, so we are describing the design rather than a control we can evidence today.

What that will cover. Every record we hold - vendors, contracts, action items, notes, and audit-log entries - along with contracts, SOC reports, certificates of insurance, due diligence documents, and attachments that arrive at your organization's inbound email address, lives in the database and in document storage that the managed disks underpin. Documents are served back to you over TLS today.

VendorLockbox adds no encryption layer of its own. We do not perform application-layer or field-level encryption above the storage layer, and we do not operate customer-managed keys. If your due diligence needs either, tell us - we would rather hear it now than describe a control we do not have.

Passwords are never stored on our servers. They are held exclusively by WorkOS, our identity provider, and hashed there under industry best practices. VendorLockbox never receives a password to store, encrypted or otherwise.

Authentication is provided by WorkOS AuthKit, a hosted identity provider used by leading fintech and SaaS products. Credential handling, including brute-force protection, is managed entirely by our identity provider under industry best practices.

Multi-factor authentication is supported for every account, on every plan, and is not restricted to paid tiers. Users turn it on from Settings › Security inside the application, which hands off to our identity provider to complete enrollment; the second factor itself and every verification code are handled entirely by WorkOS and never reach our servers. Account administrators can see each team member's enrollment status on the Team settings page. We recommend that every user with administrative access enable MFA.

Session management uses short-lived, cryptographically signed session cookies. Sessions are refreshed transparently while you are active and expire after a period of inactivity. Signing out invalidates the session immediately.

Role-based access control gives each team member one of two roles. Administrators can manage the team - inviting colleagues, removing them, and changing roles. Members can do everything else in the product but cannot change who has access.

Team invitations enforce an email match. An invitation can only be accepted by someone signed in as the exact address it was sent to, so a forwarded invite link cannot be redeemed by a different account.

Joining an organization is recorded. When someone accepts an invitation, an entry is written to an append-only audit log recording the invited address, the accepting address, and the role granted - the record of how a given person came to have access. Audit records are retained and can be produced on request; customer-facing audit reporting is on our roadmap.

Admin access to internal tooling is additionally restricted by an allowlist of authorized user identifiers. Multi-factor authentication is available to every account, administrators included, and is enabled from Settings › Security; we do not currently enforce it as a condition of admin access.

VendorLockbox is a multi-tenant application. Every record in our database, from vendors and contracts to documents and audit-log entries, is tagged with an orgId that identifies the institution it belongs to. Every query issued by the application filters on that orgId, and every API route re-validates it against the authenticated user's organization before returning data.

This organization-scoped access control is enforced in the application layer on every read and write. New endpoints cannot ship without an orgId check, and code review is part of our standard change-management process.

Files (contracts, SOC reports, certificates of insurance, due diligence documents, and attachments that arrive by email) are stored under organization-scoped storage keys. Signed URLs are used for downloads and expire after a short window.

Each organization can be issued its own inbound email address, so a vendor can send a SOC report or a certificate of insurance straight into your file. Inbound email is handled by a separate, isolated ingestion pipeline: every delivery is cryptographically signature-verified before anything is read or stored, the address resolves to exactly one organization, and attachments are written under that organization's storage keys on the same path as a document uploaded by hand. The pipeline cannot reach another organization's data, and an unverified delivery is rejected rather than filed.

Sender information is used for vendor matching - the sending domain is matched against the vendors on your file - and for naming the document something more useful than scan_0001.pdf. The sender address and subject line are never sent to the AI provider.

They are, however, retained on the document record, on the action item the arrival raises, and in your audit log. They are the audit trail for why a document was filed against a particular vendor, so an examiner asking “how did this get here” has an answer. They persist for as long as the document does, and deleting the document deletes them.

Sender verification controls let administrators require explicit approval before documents from unrecognized senders are filed. When this mode is enabled, email from org members and matched vendor contacts is accepted automatically; everything else is held in a review queue in the Action Center, where an administrator can accept it, accept it and permanently trust the sender, or reject it. Nothing from an unrecognized sender is written to your vendor file until a person approves it.

AI reads the vendor compliance documents you file: contracts, SOC reports, certificates of insurance, due diligence responses, and attachments sent to your organization's inbound email address. It also drafts prose - action item explanations, board report narratives, contract summaries - over figures already computed from your records. Every one of those outputs is a suggestion a person reviews.

For SOC reports specifically: VendorLockbox uses page classification to identify the table of contents, executive summary, scope, opinion, and findings sections, then analyzes those targeted sections. The report is not processed page by page - relevant sections are identified first, then sent to the model. This means a finding buried in an appendix section not classified as relevant may not be surfaced. Reviewers should treat the analysis as covering the key report sections, not a guarantee of exhaustive page-by-page review.

AI processing is limited to vendor compliance documents. VendorLockbox never requests or processes member data, account numbers, transaction records, or core system data. We hold no connection to your core, your loan or share records, or any member database.

Document text is processed by Microsoft Azure OpenAI Service (Azure Foundry), hosted in the United States. It is never used to train any AI model, we do not retain it after the request that reads it, and your exam readiness score is computed from your records rather than by a model. Any organization can switch AI off entirely in Settings.

Microsoft Azure OpenAI Service (Azure Foundry) is our only AI provider. Every AI feature in the product goes through it, and document text is processed inside the same Microsoft Azure infrastructure in the United States that already hosts our application, database, and encrypted file storage - it does not cross into a third party's cloud to be read.

For a complete disclosure of how AI is used, which documents are processed, and how to disable AI entirely, see our AI & Data Processing policy. It names every feature that calls a model, exactly how much of each document is sent, what a human has to approve, and our retention position:

We are actively working toward SOC 2 Type I certification. We are not SOC 2 certified today and have no report to share yet. Our current status:

• Security controls documented - complete
• Penetration test - scheduled for Q3 2026, not yet performed - in progress
• Access control policies in place - complete
• Audit logging enabled - complete
• SOC 2 Type I audit - in progress - in progress
• SOC 2 Type II audit - planned for 2027 - in progress

We will publish our SOC 2 report on this page when it is complete. If you require a current SOC 2 report to proceed, contact us at [email protected] and we will tell you exactly where the audit stands.

We maintain a documented incident response process. In the event of a security incident affecting your data, we will:

• Notify affected customers by email within 24 hours of confirming a data breach.
• Include in the notification the nature of the incident, the categories of data affected, the steps we are taking to contain and remediate, and any actions we recommend on your part.
• Provide follow-up communications and a post-incident report as the investigation progresses.
• Cooperate with your compliance and audit teams on any regulatory reporting obligations, including under NCUA guidance and any applicable state or federal law.

We welcome reports from security researchers and customers. Please email [email protected] with the details of any vulnerability you discover. Please include enough information to reproduce the issue.

Our commitments to you:

• We will respond to your report within 24 hours.
• We will not take legal action against researchers who follow this policy and act in good faith.
• We will keep you informed of remediation progress and, with your permission, credit you in any post-mortem or public disclosure.

Please do not access or modify data belonging to other customers, do not perform testing that degrades the service for other users, and do not publicly disclose the vulnerability before we have had a reasonable opportunity to remediate.

This product exists because NCUA guidance expects you to perform due diligence on your vendors. We are one of them, and we do not expect to be an exception. We are happy to provide:

• Our security overview documentation (this page)
• Answers to your due diligence questionnaire
• Reference calls with other VendorLockbox customers
• Information about our disaster recovery and business continuity plans

Contact us at [email protected] to request any of the above.