Bringing a self-hosted vector database into SOC 2 scope
An AI or search team has already loaded embeddings of internal documents into a vector store, and now the service is in SOC 2 scope because customers or auditors rely on it. A SOC 2 report is only as good as the controls behind it, so the database must meet the security and availability criteria with controls that operate and leave evidence. A default install does not do that: by default, self-deployed Qdrant instances listen on all network interfaces and have no authentication configured, and the same hardening questions apply to any vector store you host yourself.
Security is always in scope for a SOC 2 examination, through the common criteria CC1 to CC9. Availability, criteria A1, is the likely second category for a vector database that serves production search or retrieval, because its downtime affects the customer. Confidentiality, processing integrity and privacy are added only when the organization includes them, so confirm the scope with your auditor before you collect evidence for them. Also confirm which points of focus your auditor expects you to address, since the 2017 Trust Services Criteria treat them as aids to control design rather than separate requirements. The report type changes the work. A Type 1 report describes the system and tests whether controls are suitably designed as of one date. A Type 2 report adds an opinion on whether those controls operated effectively over a period, which means the auditor will sample logs, access reviews, backup records and monitoring alerts from that window. Plan for Type 2 from the start, because evidence that was never collected cannot be reconstructed later. DeployOpen plans, configures and documents these controls and prepares the evidence, but independent CPA firms issue the SOC 2 report. Ask your auditor which evidence they will sample before the first design decision.
Mapping SOC 2 requirements to vector database configuration
This table maps the SOC 2 control areas a vector database touches to the configuration each one needs and the evidence an auditor is likely to sample. Read each row as a question to answer for your own release and environment. The main takeaway is that a self-hosted Qdrant instance is unsecured until you configure it, so the controls and their evidence must be designed in from the start.
| Requirement area | What to configure and what the function must do | Evidence to prepare and what to confirm |
|---|---|---|
| Authentication and API keys | Default self-deployed Qdrant instances listen on all interfaces with no authentication. Enable admin and read-only API keys, restrict network exposure to known services, and store keys in a secrets manager. Support for these keys dates from v1.2.0. | Configuration files, secrets rotation records and a network scan showing the port is not exposed. Confirm key options against your chosen release. |
| Per-collection read and write permissions | Use JWT-based access control to grant read or write rights per collection, so each application or tenant reaches only its own vectors. This capability dates from v1.9.0. Map roles to the identity provider's groups. | Role definitions, JWT issuance and expiry settings, and access reviews showing who holds which collection permissions. Confirm the JWT model in your release. |
| TLS for REST and gRPC | Encrypt client traffic on both REST and gRPC endpoints, and encrypt traffic between cluster nodes where the topology allows it. TLS support for REST and gRPC dates from v1.2.0. Terminate certificates on hosts you control. | Certificate inventory, TLS configuration files and scan output showing only encrypted endpoints. Confirm inter-node encryption options for your deployment mode. |
| Audit logging of API operations | Enable JSON audit logging of authenticated API operations, which dates from v1.17.0. Ship logs to a central store with retention and access controls, and record who queried or changed which collection. | Sample log entries with timestamps and identities, log retention settings and evidence of log review. Confirm the logged event fields in your release. |
| Backup, snapshots and restore testing (A1.2) | Define what data needs backup, including collections, payloads and configuration. Schedule snapshots, store copies offsite, and test restores on a schedule. Restores must use a version-matched build. Requirements under A1.2 cover backup processes and recovery infrastructure. | Backup policy, snapshot logs, offsite storage records and restore test reports with dates and results. Confirm snapshot procedures in the snapshot documentation for your version. |
| Replication and quorum for availability | Run at least three nodes in production so quorum survives one node failure. Use a replication factor to keep extra copies, noting that a factor of 2 doubles storage. Choose a shard count that is a multiple of the node count. Use block storage, not NFS or S3. | Architecture diagram, node and replica counts, failover test results and capacity plans that include the storage multiplier. Confirm failover behaviour in your deployment. |
| Monitoring and alerting | Monitor node health, replication status, disk and memory use, failed authentication and error rates. Route alerts to an on-call team with documented response steps. This supports the A1.2 expectation to alert and respond to threat events. | Dashboards, alert rules, alert tickets and incident records showing response. Confirm which metrics your monitoring stack exposes for the release you run. |
| Change management for version upgrades | Track each Qdrant release, test upgrades in a non-production environment, and approve changes before rollout. Confirm that your production path supports the upgrade method you plan, since the community Helm chart lacks zero-downtime upgrades. | Change tickets, approval records, test results and rollback plans. Confirm upgrade support and features for the production path you choose. |
Which platform fits which SOC 2 control design
Self-hosted Qdrant gives you direct control over the controls auditors test, but it ships without protection. The Qdrant security documentation states that by default self-deployed instances listen on all network interfaces and have no authentication configured, so the design must start with API keys, TLS and network restriction before any data is loaded. Deployment path matters for evidence. The community Helm chart is supported by the community and lacks enterprise features such as zero-downtime upgrades and automatic shard rebalancing, while the enterprise Kubernetes operator is offered as part of Qdrant Private Cloud.
- Access control: Admin and read-only API keys, and JWT-based per-collection read or write permissions since v1.9.0, let you show least privilege for each application.
- Encryption: TLS for REST and gRPC has been supported since v1.2.0, so the transport control can be documented as configured and tested.
- Audit logging: JSON audit logging of authenticated API operations since v1.17.0 gives you the record of who changed or queried which collection.
- Upgrades: Under the community Helm chart, plan upgrade downtime and change management yourself, since zero-downtime upgrades are an enterprise feature.
- Storage: Block storage with a POSIX-compatible file system is required, so backup and restore evidence must cover the volume layer as well as snapshots.
Confirm with Qdrant which deployment path and version your auditor will see, and keep the configuration files that prove each setting was applied.
Milvus documents authentication, TLS encryption and role-based access control in its README, so access control can be designed around roles rather than only API keys. The architecture is more components to evidence. Standalone runs on a single machine, while Distributed runs as a Kubernetes-native cluster with stateless proxies, coordinators and worker nodes. Metadata sits in etcd, object storage is MinIO, S3 or Azure Blob, and the write-ahead log is Woodpecker, Kafka or Pulsar, so each dependency needs its own backup, access and monitoring evidence.
- Access control: Role-based access control and authentication are documented in the README, so map roles to the teams that query or write each collection and confirm the granularity you need.
- Encryption: TLS is documented, so confirm it covers every internal and client path your architecture uses.
- Dependencies: etcd metadata, object storage and the write-ahead log each hold data or state, and each must appear in the backup and recovery design.
- Deployment mode: Standalone suits a single-node scope, while Distributed brings more components whose configuration and changes must be controlled.
- Release lines: Two lines are maintained, with v3.0.3 and v2.6.25 both published in 2026, so pick one and document the upgrade path.
Ask for evidence of the RBAC policy, the TLS configuration for every component, and a restore test that covers etcd and object storage together.
Adding pgvector to a PostgreSQL instance you already operate lets you reuse controls that auditors may already have tested, including database roles, backup schedules, and monitoring. The trade-off is that vector search inherits the scope of the database. Any user or service with access to the database can reach the embeddings, so per-collection separation has to be designed with schemas, roles and row-level policies rather than a dedicated vector permission model. This is a sound starting point when the vector scale and query rate are modest and the team already runs PostgreSQL under controls.
- Reused controls: Existing database roles, access reviews, backup policies and restore tests can be cited directly in the system description.
- Access design: Separate schemas or roles per data set, and row-level security where entitlements differ, must be documented and sampled.
- Audit logging: Confirm whether your PostgreSQL logging captures the queries and changes that matter for vector data, since that is not the same as a per-operation audit trail of the vector API.
- Scope boundary: The embeddings enter the same boundary as the source database, so classify them with the same data rules.
- Scale signal: When the access model, backup window or query load strains the shared database, the design should be reviewed for a dedicated vector store.
Confirm with your database team that the controls you plan to cite are already in operation and tested, not only documented.
Qdrant Cloud and Zilliz Cloud move part of the control design to the provider. Qdrant Cloud offers a usage-priced Standard tier with a 99.5% uptime SLA and a Premium tier with a minimum spend that adds SSO, private VPC links and a 99.9% uptime SLA. Zilliz Cloud offers Serverless, Dedicated and bring-your-own-cloud options. Qdrant Hybrid Cloud runs managed clusters on your own infrastructure, which keeps more of the control evidence in your scope. Each choice changes the system description, so the provider's report or evidence must be obtained and mapped to the criteria it covers.
- Shared responsibility: Infrastructure, patching and some access controls may sit with the provider, so your description must state which controls are carved out.
- Provider evidence: Request the provider's current SOC report or equivalent and confirm its scope, period and any complementary user entity controls you must operate.
- Availability terms: The SLA figures are contractual commitments, not a substitute for your own backup and recovery testing.
- Data location: Confirm where embeddings and snapshots are stored, and which regions and sub-processors touch them.
- Deployment model: Hybrid or bring-your-own-cloud options keep more controls in your scope but add operations work.
Ask the provider which criteria its evidence covers and which ones you must evidence yourself, then reflect that split in your system description.
Platforms that fit a SOC 2 vector store
Each option below can hold document-derived vectors inside your infrastructure, but none makes the store SOC 2 ready on its own. The cards show what each platform provides for access control, encryption, logging and recovery, and what your team still has to design, operate and evidence before an auditor samples it.
Qdrant self-hosted
Qdrant offers API keys, TLS for REST and gRPC, per-collection read or write permissions through JWT-based access control, and JSON audit logging of authenticated operations. The default install is not secure: instances listen on all interfaces with no authentication, so the team must set this up before any data is loaded. Still to build: role design, key rotation, log shipping to your SIEM and snapshot-based recovery tests. Confirm which production path you will run, since the community Helm chart lacks enterprise features such as zero-downtime upgrades.
Milvus self-hosted
Milvus implements authentication, TLS encryption and role-based access control, and offers multi-tenancy at database, collection, partition or partition key level. Its Distributed mode relies on several components, including etcd for metadata and object storage such as MinIO, S3 or Azure Blob, so your SOC 2 boundary grows with each dependency. Confirm how each component's encryption, access and backup is configured, and which Milvus release line you will standardize on before writing your control descriptions.
pgvector on existing PostgreSQL
If your PostgreSQL estate already has audited access controls, encrypted connections, log retention and tested backups, pgvector inherits much of that evidence. Vector data then sits under the same roles and backup jobs your auditors already sample. The gaps are index tuning, dimension and filtering behavior, and whether one database can meet availability targets as collections grow. Document which PostgreSQL controls cover the embedding tables, and confirm they are not excluded from your existing backup scope.
Managed provider with shared responsibility
A managed service such as Qdrant Cloud or Zilliz Cloud moves patching, uptime and some infrastructure controls to the provider, but your organization still owns identity, data classification, what gets embedded and what the vendor's SOC report covers. Request the provider's current SOC report and map each control to your own system description, so you know which gaps remain yours. Confirm the provider's uptime commitment and whether private networking is included in the tier you would buy.
Choosing by scale and operations skills
The right platform depends on how many vectors you will hold, how often you will query them, and whether your team already runs distributed stateful systems. A single node with strong PostgreSQL operations may pass audit more easily than a cluster your staff cannot monitor. Qdrant distributed mode recommends at least three nodes for production quorum, so the operations burden is real. Decide with your operations lead, then write the control set for the platform you actually run.
Configuring the database before the first audit period
This sequence turns a vector database that ships without authentication into one whose access, encryption, logging, recovery and change records can be sampled against the SOC 2 criteria. Each step produces a setting, a record or a test result that an auditor can examine.
Restrict network exposure and enable authentication
The platform team binds the Qdrant service to the internal network interfaces it needs, places it behind a private network path, and turns on API key authentication before any application or user connects. Qdrant's security documentation states that self-deployed instances listen on all interfaces with no authentication by default, so this step closes the gap first. Done means a scan from outside the approved subnets is refused and an unauthenticated request to the API returns an authorization error. Keep the firewall rule set and the test output as evidence for the logical access criteria in CC6.
Issue admin and read-only API keys
The security team creates one admin key for the database operators and separate read-only keys for services that only query collections. Keys are generated in the secrets manager of the organization, not in configuration files or chat tools, and each key's owner and purpose are recorded in the access register. Done means the read-only key is rejected on a write request and the admin key is held by named operators only. This supports the access provisioning and least-privilege evidence that CC6 criteria ask about.
Define JWT roles with per-collection permissions
Using JWT-based access control, the identity or platform team defines roles that grant read or write permission on specific collections, such as one role for the HR policy collection and another for the product documentation collection. Role mappings are reviewed against the identity provider groups the organization already uses for joiners, movers and leavers. Done means a test token for one role can read its collection but cannot read a restricted collection, and the test results are saved. Qdrant documents this granular control from v1.9.0, so the team should confirm the version in use before relying on it. The role matrix is evidence for CC6 access restriction.
Enable TLS for REST and gRPC
The platform team issues certificates from the organization's internal certificate authority and configures TLS on both the REST and gRPC endpoints, so that embeddings, queries and API keys are never sent in clear text between services. Clients are updated to trust the internal CA and to reject plain connections. Done means a connection attempt without TLS fails and a scan of the endpoints shows only current protocol settings. Qdrant documents TLS for both interfaces from v1.2.0. The certificate inventory, renewal owner and scan results support the encryption in transit criteria under CC6.
Turn on audit logging and ship logs to the SIEM
The operations team enables Qdrant's JSON audit logging of authenticated API operations, which Qdrant documents from v1.17.0, and forwards those logs to the central log platform with a retention period set by the organization's policy. Log fields are checked against a sample request so that the actor or key identity, the collection, the operation and the timestamp are present. Done means a test write and a test read both appear in the central platform within the expected window and the retention rule is confirmed. This is the monitoring evidence that CC7 criteria on system operations and anomaly detection sample. If the workload also falls under other logging obligations, such as the EU AI Act record-keeping articles for high-risk systems, confirm those separately.
Schedule snapshots and test a restore
The operations team schedules regular snapshots of each collection, stores them on a separate backup location with its own access controls, and defines which collections require backup under the organization's recovery objectives. A restore is then performed into a separate test instance running the same version as production, and the restored collection is checked for point counts and sample query results. Done means a signed restore record exists with the snapshot identifier, the date, the operator and the outcome. Qdrant's snapshot documentation describes the mechanism, but the recovery time and frequency should be set by the organization, not taken from a vendor default. This record supports the availability criteria in A1.2 on data backup and recovery.
Pin versions and document the change process
The platform owner pins the Qdrant image or Helm chart to a specific tested version, records it in the configuration repository, and defines a change procedure covering test upgrades, approval, rollback and communication to application owners. Upgrades are only applied after the restore test has been run against the new version. Done means the change ticket for the current version, the approval record and the rollback plan are on file, and the pinned version matches what is running. This evidence supports the change management criteria in CC8 and makes the system description accurate for the auditor.
Evidence auditors ask for from the vector database
This table lists the evidence an auditor is likely to request for a self-hosted vector database, the component that produces each item, and what the auditor will sample across the period for a Type 2 report. Use it to plan which exports, logs and tickets must exist before the examination window opens, not after.
| Evidence item | Producing component | What the auditor samples across the period |
|---|---|---|
| Access review exports of API keys and role assignments | Qdrant admin and read-only API keys, JWT role and per-collection permission definitions, and the identity provider or secrets manager that issues them | Periodic review records showing who held admin, read-only and per-collection read or write access, with evidence that stale or departed users were removed |
| Configuration baselines for TLS and authentication | Qdrant REST and gRPC TLS settings, authentication configuration, network bind settings, and infrastructure-as-code or Helm values under version control | Current and historical configuration showing TLS enabled and authentication required, plus change records for any deviation from the baseline |
| JSON audit log samples and retention | Qdrant JSON audit logging of authenticated API operations, forwarded to the central log store | Sample entries tying an operation to an identity and collection, and proof that logs were retained and could not be edited by the operators who generate them |
| Snapshot schedules and restore test records | Qdrant snapshots, the storage layer holding them, and the backup scheduler or job logs | Schedule definitions, completed snapshot records, and dated restore tests showing that a snapshot was restored and the collection was checked against expected results |
| Replication and node health monitoring | Qdrant cluster status and replication factor settings, Raft quorum state, and the metrics pipeline and alert rules | Dashboards or exported metrics for node count and replica state, and alert tickets with responses for node loss or degraded replicas |
| Change and upgrade tickets | Ticketing system, deployment pipeline, and version records for the Qdrant release in use | Approved change requests for version upgrades and configuration changes, test evidence before release, and rollback plans linked to each change |
| Incident records | Incident management tool, audit log alerts, and post-incident reviews | Incident tickets covering failed logins, unauthorized access attempts, outages and restores, with root cause, corrective action and closure dates |
What tooling alone does not satisfy
A vector database can enforce access, encryption and logging, but SOC 2 examines the whole operating system around it. The cards below cover the controls that sit with people, vendors, pipelines and evidence, which an auditor will ask about whether or not the database is configured correctly.
Written policies and access reviews
Auditors sample the policies that govern who may create collections, hold admin keys and read vector payloads, then ask for proof that those rules were applied. Qdrant's per-collection permissions and API keys only help if someone reviews who holds them each period and removes access when people change roles or leave. Check that your access review covers API keys, service accounts and the embedding pipeline's credentials, not just human logins.
A named owner and on-call process
The availability and operations criteria expect a defined owner for the vector store, with documented alerting, escalation and response. A distributed cluster needs someone who can act on quorum loss or a failed restore at any hour, and that person must be known to the auditor. Confirm who approves changes, who is paged, and where incident tickets for the database are recorded.
Vendor and sub-processor review
A managed option such as Qdrant Cloud, Zilliz Cloud or a hybrid deployment introduces a service provider whose controls become part of your system description. Obtain the provider's own SOC report or equivalent evidence, confirm where its staff can reach your data, and record each sub-processor in your vendor inventory. For a self-hosted deployment, the same review applies to your hosting provider and any managed backup target.
Embedding pipeline and deletion controls
Vectors are derived data, so a source record deleted in one system can persist in embeddings, payloads and snapshots. Define how a deletion request reaches the vector store, how points are removed, and how old snapshots and backups are handled. Keep a record that each deletion job ran and succeeded, because an auditor will sample that record against the change and data handling controls.
Log retention and central monitoring
Qdrant's JSON audit log of authenticated API operations is only useful if it leaves the database host. Ship logs to a central store that the database administrators cannot edit, set a retention period agreed with your compliance lead, and alert on failed authentication and admin key use. Check that clock sources match across the database, proxies and the log platform so events can be ordered during an investigation.
Operating evidence across the period
A Type 2 report tests whether controls operated over a period, so a configured setting on the day of the audit is not enough. Keep dated evidence of access reviews, backup jobs, restore tests, patch records and alert responses throughout the period. Ask the assessor which artifacts they will sample and agree on the format before the period starts, since assembling this after the fact is slow and often incomplete.
Questions buyers ask before SOC 2 work on a vector database
What does SOC 2 work on a vector database cost, and what drives it?
The cost depends on the scope of the examination, the number of platforms and environments in it, and the volume of evidence the auditor will sample. Your organization pays the CPA firm for the examination itself, and that fee is separate from any implementation work. Implementation work covers hardening the database, configuring authentication and per-collection permissions, TLS, audit logging, backup and restore, and monitoring. Ask any partner for a fixed-scope quote that lists each platform, each control area and each evidence artifact, and ask your CPA firm for its own fee estimate. Recurring costs include infrastructure, log retention, periodic restore tests and access reviews, while the hardening work is largely one-time.
How long does a SOC 2 readiness project take?
Duration is set by how many controls are already in place, how many systems the examination covers, and how quickly your team can produce evidence. A database that ships without authentication needs more hardening work than one already behind your identity provider and logging pipeline. The examination window is also a factor: a Type 2 report covers operating effectiveness over a period, so controls must run long enough to be sampled. Ask any partner for a written timeline with milestones, the evidence each milestone produces, and the dependencies on your identity, network and change management teams. Your CPA firm can confirm the examination period it expects.
What does the internal team need to provide?
Your team must own the decisions and the evidence. Typically that means a named owner for the vector database, someone who manages identity and access in your identity provider, a network or platform engineer for TLS and interface binding, and a contact for backup and incident procedures. Your team also approves the control design, reviews access, and signs off on the management representations the examination depends on. Ask a partner which of these roles they expect you to fill, how many hours of participation they assume, and who holds the evidence after the engagement ends.
Can a small team do SOC 2 work on a vector database alone?
A small team can do it, but only if it has clear ownership and enough time for both the engineering and the recurring evidence work. The Qdrant security documentation notes that self-deployed instances listen on all interfaces and have no authentication by default, so the first tasks are configuration tasks that a capable engineer can handle. Ongoing duties such as access reviews, log review, restore tests and change records are where small teams struggle. Ask yourself whether those duties have a named owner and a calendar. A partner can deliver the initial build and documentation, and you can keep the recurring work in house.
Should we start with a SOC 2 Type 1 or Type 2 report?
A Type 1 report covers the system description and the suitability of control design as of a specific date. A Type 2 report adds an opinion on operating effectiveness over a period. Many organizations use a Type 1 as a first milestone because it tests whether the controls are designed correctly before the longer observation window starts. Buyers who need evidence of sustained operation usually need the Type 2. Confirm with your CPA firm and your customers which report they will accept, because that answer decides the sequence of work.
Does a managed vector database service remove the SOC 2 work?
A managed service moves some controls to the provider, but it does not remove your obligations. Your organization still owns its identity model, per-collection permissions, data classification, retention, deletion requests and the evidence that these controls operate. Ask the provider for its own SOC report, its shared responsibility matrix, and the specific controls it covers for the service you would use. Qdrant's pricing page describes a managed tier with a stated uptime SLA and a private network option, and you should compare those terms against the criteria in your own scope. Self-hosting shifts more of the operating evidence to your team, so the comparison should be made against your own control inventory.
How does a SOC 3 report differ from a SOC 2 report?
A SOC 3 report covers the same trust services categories as a SOC 2 in less detail, and it is a general use report that can be freely distributed. A SOC 2 report is restricted in use, so it is normally shared under a non-disclosure agreement with customers, prospects and partners who need it. Choose a SOC 3 when you need a public statement of assurance, such as for a website, and a SOC 2 when prospects want the control descriptions and test results. Your CPA firm can explain which report fits your sales and procurement needs.
What the team should decide before scoping
The first decision is the system boundary, because an auditor only tests what the system description says is in scope. Write down every environment that holds vectors or can reach them: production, staging, any restored copy used for testing, and the snapshot and backup stores that hold the same points. Then decide which data sources feed the embedding pipeline and which application services query the store, since each is a dependency the AICPA 2017 Trust Services Criteria controls will need to cover. Confirm with the audit firm early whether the Security category alone is enough or whether Availability or Confidentiality are added, because that choice changes how much of the backup and recovery design is examined.
The second decision is whether the vector store holds data derived from personal or customer information. Embeddings and their payload fields often carry the same content as the source documents, so treat them as in scope for access control, retention and deletion even if no one thinks of them as data. Record which source systems, classifications and tenants feed each collection, and decide whether payloads store the original text or only identifiers. Those answers determine how restricted the per-collection permissions must be and whether deletion when a source record changes is a control the auditor will sample.
The third decision is the shared responsibility split. If you use a managed offering such as Qdrant Cloud or Zilliz Cloud, obtain the provider's own SOC report and confirm which controls it covers, such as physical hosting, patching and backup of the service, and which remain yours, such as API keys, role assignments, TLS certificates and restore testing. Under a self-hosted or Hybrid Cloud model, the whole stack falls to your team. Assign named owners now for the quarterly access review of collection permissions and for the scheduled restore test, and decide who signs off the evidence. Unowned controls are the ones that fail sampling.
How a SOC 2 vector database engagement runs
The engagement moves from a written scope and evidence list to hardened configuration, an auditor-ready evidence set and tested restores and monitoring, so the organization's own auditor can sample controls with less friction. DeployOpen prepares the systems and evidence; the independent CPA firm performs the examination and issues any report.
Agree the written scope and system boundary
DeployOpen and the client agree in writing which vector collections, applications, identity sources, networks and data categories fall inside the system described for the SOC 2 examination, and which trust services categories are in scope beyond security. The client's auditor should review the boundary before work starts, because the system description is management's responsibility. The step closes when the scope document and a draft evidence list are signed off by the client.
Map controls to the evidence list
Working from the agreed boundary, DeployOpen maps each relevant control area, including logical access, change management, system operations, availability and monitoring, to the artifacts an auditor would expect to sample, such as configuration exports, access reviews, log extracts and restore records. The client confirms which owner produces each item and how often. The step closes with a control-to-evidence matrix that the client's auditor has seen.
Harden the deployment and its configuration
Engineers replace the insecure defaults of a self-deployed Qdrant instance or the equivalent settings in Milvus or pgvector: network binding, API keys or JWT-based per-collection permissions, TLS for REST and gRPC, and secrets handling. Changes are made through version-controlled configuration so each setting can be shown later. The step closes when a configuration review confirms that no endpoint is reachable without authentication and that the settings match the evidence matrix.
Enable audit logging and document operating procedures
DeployOpen turns on audit logging of authenticated API operations, routes logs to storage the client controls with a defined retention period set by the client, and writes runbooks for access requests, key rotation, change approval, incident response and backup operations. The client's operators are walked through the procedures so they can perform them without DeployOpen. The step closes when a test operation appears in the log store and the runbooks are approved by the client.
Prepare the evidence collection workflow
DeployOpen sets up a repeatable way to collect the evidence list: scheduled exports of configuration and access lists, dated log samples, change tickets linked to deployments and backup job reports, stored in a location the audit team can reach. Collection is written as a procedure so that the same evidence can be produced for the observation window the auditor selects. The step closes when a dry run produces a complete evidence package that the client has reviewed for gaps.
Test restores and monitoring alerts
Backups of collections and snapshots are restored into an isolated environment, and the restored data is checked against the source counts and sample queries, with timings and results recorded. DeployOpen also triggers test alerts for failed authentication, service unavailability and backup failures and confirms that they reach the on-call channel the client named. The step closes with dated restore and alert test records that the client can hand to its auditor.
Hand over the evidence and agree support options
DeployOpen delivers the system documentation, the evidence package, the runbooks and a list of open items to the client's compliance and engineering leads, and walks the auditor's contacts through how evidence is produced if the client asks for that. Ongoing work such as quarterly access reviews, upgrades, restore testing and continuous security testing can be covered by a retainer agreed in writing. The step closes when the client confirms receipt and the retainer scope, if any, is signed.
How DeployOpen delivers SOC 2-ready vector infrastructure
DeployOpen plans, implements, hardens and documents self-hosted vector databases inside the client's own cloud accounts, data centers or air-gapped networks. For SOC 2, the work centers on the controls auditors sample: authentication, per-collection permissions, TLS, audit logs, backup and restore, and monitoring evidence, all prepared for the independent auditor to examine.
How we scope
- Agree which systems, collections and data flows fall inside the SOC 2 system description before any build starts.
- Map each in-scope Trust Services Criterion to the vector store configuration, owner and evidence source it depends on.
- Confirm the engagement is fixed-scope, with deliverables and timelines agreed in writing before work begins.
How we build
- Deploy the chosen engine with authentication enabled, API keys or role-based access, and TLS on REST and gRPC endpoints.
- Configure per-collection read and write permissions, audit logging of authenticated operations, and retention for those logs.
- Run security testing against the API and host, and document the cluster, storage and network settings the auditor will ask about.
How we hand over
- Deliver the system description inputs, configuration baselines, access matrix and runbooks in a form your auditor can sample.
- Document backup schedules, snapshot procedures and a restore test with recorded results, including version-matched restores.
- Train your operations and security staff on access reviews, log review and evidence collection so the controls keep running after handover.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after handover, if your program needs it.
- Track version upgrades and patch cycles so configuration and evidence stay current through each audit period.
- Confirm with your auditor which evidence formats they accept and how often they expect samples, before the observation window opens.
