Why a self-hosted vector database for the public sector needs a boundary decision first
An agency team that wants semantic search over case files and records has to settle one question before it compares products: where the vector store is allowed to sit. The vector store must run inside the agency's authorized boundary, and the hosting and authorization rules decide which open-source platform and deployment pattern fit. Choosing Qdrant or Milvus first and checking authorization afterward tends to produce a design that cannot be approved without rebuilding it. Embeddings derived from records inherit the sensitivity of their source. A vector built from a case note is still a representation of that note, so the store holds regulated content even though it contains numbers rather than text. FedRAMP scope turns on whether a cloud service creates, collects, processes, stores or maintains federal information on behalf of an agency, so a managed vector service may fall in or out of scope depending on how it is offered and used. CJIS Security Policy, NIST SP 800-53 baselines and the agency's records retention schedule apply to derived data too, which means the team must decide how long vectors live, how they are deleted when source records change, and which backups hold them. The short answer on platforms is that Qdrant or Milvus fit a dedicated vector search service that the agency can deploy and control inside its boundary, while pgvector fits where the agency already runs PostgreSQL in an approved environment with the backup and access controls it needs. Confirm each of these with the agency's authorizing official and the controls baseline in force, since no authorization outcome can be assumed from the platform choice alone. The NIST SP 800-53 Rev. 5 catalog is the natural reference for mapping those controls.
Which public sector rules shape the vector database build
This table maps the federal, criminal justice, CUI, accessibility and EU rules most likely to touch a vector search build for agency records, and what each means for hosting, keys, scanning, interfaces and evidence. Read each row against your data category and authorizing official, because several rules apply only when a specific trigger is present.
| Rule or requirement | What it means for the build | Applies when |
|---|---|---|
| NIST SP 800-53 Rev. 5 baselines | Low, moderate and high baselines select 149, 287 and 370 controls and enhancements. Map the vector store, embedding pipeline and admin tools to the chosen baseline and keep control evidence per component. | Federal systems or agencies that adopt the catalog through an authorization process |
| FISMA and Inspector General review | Agency system security is assessed independently and reported to OMB. Plan for evidence the Inspector General may sample, including access reviews, configuration baselines and incident records for the vector store. | Federal agency information systems |
| FedRAMP scope under OMB M-24-15 | A cloud-hosted vector service that stores federal information for an agency falls within FedRAMP's cloud scope. A single-agency system on cloud infrastructure not offered as a shared service may fall outside it, so confirm the boundary before choosing a host. | Cloud hosting of federal information |
| CJIS Security Policy v6.1 encryption | Criminal justice information in transit and at rest outside physically secure locations needs FIPS 140-3 validated modules or AES with at least 256-bit keys. Confirm key lengths for TLS, disk encryption and snapshots before deployment. | Embedded content includes criminal justice information |
| CJIS vulnerability scanning | Vulnerability scanning must run at least monthly under the policy. Schedule scans for the vector database host, container images and the embedding service, and retain scan reports as evidence. | Systems that process criminal justice information |
| 32 CFR 2002.14(h)(2) for CUI | Agencies must use NIST SP 800-171 when setting requirements for controlled unclassified information on non-federal systems, unless the CUI category prescribes other safeguards. A hosted or contractor-run vector store holding CUI needs those safeguards written into its requirements. | Records contain CUI and the system is not federal |
| 32 CFR 170.17(c)(5) for cloud CUI | A defense contractor seeking CMMC Level 2 may store CUI in a cloud service only if it is FedRAMP Authorized at Moderate or higher, or meets equivalent requirements. Confirm this before selecting managed or hybrid hosting. | Contractor systems handling defense CUI |
| ADA Title II web accessibility (WCAG 2.1 A and AA) | Public-facing search interfaces must meet WCAG 2.1 Level A and AA. Covered entities serving 50,000 or more people must comply from 26 April 2027, and smaller entities and special districts from 26 April 2028. Test search results, filters and citation displays with assistive technology. | State and local government entities serving the public, including contracted or licensed web content |
| NIS2 scope for public administration | Central government entities fall in scope regardless of size, and Member States may extend coverage to local administration. NIS2 excludes entities working in national security, public security, defense or law enforcement. Document the risk measures and incident handling that cover the vector store. | EU public administration entities, subject to national implementation |
Which open-source vector platforms fit agency deployments and why
Agencies rarely need the most features. They need a store that can run inside the government boundary, enforce access control tied to the agency's identity provider, and be backed up and restored on infrastructure the agency already audits. The options below differ mainly in how much of that security work the product provides and how much the agency must build.
Qdrant for controlled collections
Qdrant is Apache-2.0 licensed, and v1.19.2 was released on October 5, 2026. It offers admin and read-only API keys, TLS for REST and gRPC, JWT-based permissions per collection since v1.9.0, and JSON audit logging of authenticated operations since v1.17.0. Qdrant is insecure by default: self-deployed instances listen on all interfaces with no authentication, so hardening is part of the first deployment. It also needs block storage with a POSIX file system, so NFS or S3-backed volumes are not valid targets. Confirm the storage class in the boundary before sizing.
Milvus for disaggregated scale
Milvus is Apache-2.0 licensed and ships authentication, TLS and role-based access control. Its multi-tenancy works at database, collection, partition or partition key level, which maps to agency programs or case-file classes. The Distributed mode is Kubernetes-native and depends on etcd for metadata and object storage such as MinIO, S3 or Azure Blob, plus a write-ahead log. Each dependency adds components the agency must back up, patch and evidence. Confirm which release line, v3.0.3 (October 14, 2026) or v2.6.25 (September 29, 2026), the agency's assessor accepts.
pgvector on existing PostgreSQL
pgvector adds vector search to PostgreSQL that the agency may already run under approved backup, high availability and database access controls. This can be the shortest path to an authorization decision because the boundary, logging and recovery procedures already exist. The trade-off is that filtering, index limits and scale depend on the PostgreSQL design. Check whether row-level security can enforce the agency's record-level permissions, and whether the existing audit trail captures vector queries as well as writes.
Managed Qdrant and Zilliz options
Qdrant Cloud and Zilliz Cloud are managed services. Whether they can hold federal, CJI or controlled unclassified data depends on the hosting region, the provider's authorization status and the data category, and the agency must verify both directly. Qdrant Hybrid Cloud runs managed clusters in the agency's own infrastructure, and Qdrant Private Cloud is a dedicated deployment; both are priced through Qdrant sales, so ask for written scope and terms before comparing costs.
RAG and chat layers as consumers
Chat and retrieval applications sit on top of the store and do not replace it. Whatever front end the agency chooses must query only collections the requesting user may read, and it must write its own logs of prompts and retrieved sources. Treat the vector store's access model as the control and the chat layer as one client of it. For retrieval design, see the RAG knowledge assistant implementation group.
How classification and records retention apply to embedded content
An embedding is derived data. It encodes meaning taken from the source record, so the agency should classify every vector at the highest classification of the source it encodes. The same rule applies to the payload text, chunk references and source IDs stored beside each vector in Qdrant or Milvus, for example a source_id or chunk field. Those fields carry the content itself, so they need the same marking as the original document, and the collection that holds them should be restricted to users cleared for that marking. A vector store that holds mixed-classification content in one collection without per-collection permissions is a design decision the agency should reject early, before any data is loaded.
Records retention applies to the vectors as well. Embeddings, their payloads and the snapshots or backups that contain them should be treated as copies or records to be disposed of on the same schedule as their sources. Deleting a source record must therefore trigger deletion of its points and payloads in the live collection and a plan for the copies that remain. Those copies are where stale vectors survive. Qdrant snapshots and the object storage behind Milvus backups can keep data long after the live index has been cleaned, so the agency needs a documented rule for how and when those backup sets expire, and it should confirm with its vendor and operations team how a point deletion propagates to them.
Retention schedules and record classification rules come from the agency's own records officer and the governing law, not from the vendor. Ask the records officer whether the derived vectors are a record in their own right, a copy of a record, or a transient index, because the answer sets the disposal trigger. Then write the rule into the deletion procedure, test it by deleting a sample source and checking the live collection and a restored snapshot, and keep the evidence of that test with the retention records.
Tying vector search access to the agency identity provider
Many applications connect to the vector database with a single API key stored in configuration. The key proves that the calling service is allowed to reach the database, but it says nothing about which agency employee asked the question. The identity provider authenticates the person in the browser or portal, and that identity is lost once the application makes its own call. Qdrant supports admin and read-only API keys and TLS, and by default self-deployed instances have no authentication configured, so a shared key is only a starting point. For user-level access to agency records, this option is not acceptable.
- Identity loss: the audit log shows the service account, not the caseworker or the citizen-facing request that triggered the search.
- Over-broad scope: an admin key can read and write every collection, so one leaked key exposes the whole index.
- Revocation gap: removing a user from the identity provider does not remove access, because the key does not change.
- Rotation burden: key rotation touches every application at once and tends to be deferred.
- Acceptable use: service-to-service jobs such as embedding pipelines, limited to their own collections with least privilege.
Confirm with the agency security team that no application holds a key that can read a collection holding case files for all users.
Here an API gateway or middleware sits between users and the vector database. It validates the identity provider's token, maps the user's groups to a role, and then calls the vector store with credentials that carry only that role's permissions. Qdrant supports JWT-based access control with per-collection read or write permissions since v1.9.0, which lets a gateway or token issuer scope each token to specific collections. Milvus implements authentication, TLS and role-based access control, which can be mapped to database and collection privileges. Whether a given identity provider connects to either platform natively is not confirmed in the supplied documentation, so connector support must be checked directly with the vendor and the agency's gateway product.
- Token validation: the gateway checks signature, expiry and audience against the agency identity provider before any vector call.
- Role mapping: agency groups map to read or write roles per collection, reviewed with the records owners.
- Short-lived credentials: the vector store token is minted per session, so a revoked user loses access when the token expires or is refused.
- Central logging: the gateway records the user identity alongside the query, which supports the audit evidence auditors sample.
- Confirmation step: verify whether the chosen Qdrant or Milvus release and gateway support the claims you need before committing to a design.
Test that a user removed from the identity provider group receives an authorization failure on the next query, not only after the token expires.
Some collections hold records that different users may see only in part, such as case files restricted by unit, legal hold or classification. In this option each stored point carries entitlement fields in its payload, such as an owning unit or a sensitivity marker, and every search applies a filter that matches the caller's entitlements. Milvus offers partition key tenancy and multi-tenancy at database, collection, partition or partition key level, which can narrow the search space by unit. Qdrant applies payload filters during search, so filtering is part of the query rather than a separate step. Filters only protect data when the caller cannot change them, so the filter must be built server-side from the verified identity.
- Server-side filter construction: the application builds the filter from the gateway-verified claims, never from user input.
- Entitlement fields maintained at ingest: the embedding pipeline writes owner and classification fields from the source system of record.
- Partition key choice: use a partition key for high-cardinality tenancy such as units, and separate collections for hard boundaries.
- Revocation on change: entitlement updates must be propagated to stored payloads or the filter source, not left to a nightly job.
- Residual risk: embeddings and snippets can leak content through similarity, so filtering should be combined with the gateway controls above.
Before go-live, run negative tests with an account that lacks each entitlement and confirm no result, snippet or count returns.
How an agency rollout moves from authorization to production search
The sequence takes an agency from an agreed authorization boundary and data categories to a vector search service that has passed hardening, restore, retention and access checks, and is released first to a limited pilot group. Each phase closes with a written output that the authorizing official and security staff can review.
Confirm the authorization boundary and data categories
The agency's authorizing official, information system owner and privacy or records officers agree on which systems fall inside the boundary, which record series and case files may be embedded, and the highest data category that will be stored as vectors. DeployOpen supports this work by mapping the proposed architecture to the controls the agency already applies, but the decisions remain with the agency. The step closes with a signed boundary diagram, a data category register and a list of systems that are explicitly excluded, including any embedding model or hosted service that receives source text.
Apply the hardening baseline before any data loads
Engineers configure the vector database before it holds any agency content. Qdrant ships without authentication and listens on all network interfaces by default, so the baseline enables API keys, restricts listening interfaces to the approved network segment and turns on TLS for REST and gRPC. Milvus deployments need authentication, TLS and role-based access enabled in the same way. The step closes with a configuration review against the agreed baseline, a scan showing no unauthenticated listener on any interface, and a record of the image versions used.
Design storage and deployment for quorum and recovery
Architects select the deployment model and storage. Qdrant needs block storage with a POSIX-compatible file system, not NFS or object storage, and the distributed deployment docs recommend at least three nodes for production so quorum survives a node failure. Milvus Distributed uses object storage such as MinIO, S3 or Azure Blob together with etcd and a write-ahead log, which adds components the operations team must support. The step closes with a sized design that states node count, replication factor, storage class and the components inside the boundary, reviewed by the agency's infrastructure team.
Build the ingestion and classification pipeline
Engineers build the pipeline that reads source records, applies the classification rules from the first step, chunks text, generates embeddings with an approved model running inside the boundary, and writes points with metadata such as record identifier, classification label, source system and retention class. Records above the approved category are rejected at ingestion rather than filtered at query time. The step closes with a test run on sample records showing that each vector carries its source reference and label, and that rejected records are logged with a reason.
Integrate access control with the agency identity provider
Identity engineers connect the search service to the agency identity provider so that users and groups map to per-collection read or write permissions. Query results should be filtered by the caller's entitlements before they leave the service, and the mapping must be tested with accounts that hold different roles. The step closes with a permission test matrix showing that each test account can retrieve only the collections and classification labels it is authorized to see, plus a documented process for removing access when an employee leaves or changes role.
Test backups and restores with version-matched snapshots
Operators schedule snapshots of each collection and run restores into a separate environment running the same engine version. Restores are checked by comparing point counts, sample queries and permission behavior against the source. Snapshots and backups are treated as records that hold the same content as the live store, so they fall under the same classification and retention rules. The step closes with a restore test report that records the version used, the time taken as measured in the test, and the results of the comparison, signed off by the system owner.
Document the retention and deletion procedure
Records and privacy staff define how derived vectors follow their source records. The procedure covers how a source record's retirement or erasure triggers deletion of its points and payloads, how that deletion reaches snapshots and backups, and who approves exceptions where a legal hold applies. Engineers implement the procedure as a scripted job with logging. The step closes with an approved procedure and a test deletion that shows the vectors, payloads and affected backup copies were removed or marked for expiry, with evidence retained.
Collect evidence for the authorizing official
The team gathers the artifacts the authorizing official and any independent assessor will sample: the boundary and data register, configuration baseline results, access test matrix, audit log samples from the JSON audit logging the engine provides, backup and restore reports, deletion test results and the change record for each version in use. Confirm with the agency which control catalog and baseline it assesses against before collecting, so evidence maps to the right control identifiers. The step closes with an evidence index that cross-references each artifact to a control and an owner. Final authorization decisions remain with the agency and its assessors.
Release to a limited pilot group
The service opens to a small, named group of users who work with the approved record series. Pilot users confirm that results are relevant and that restricted items do not appear, and the team monitors query logs, error rates and access denials. Any gap found in the pilot returns to the step that owns it, and the boundary is not widened until the agency accepts the pilot results. The step closes with a pilot report listing findings, their resolution and the agency's written decision to move to production search.
Evidence assessors and records officers ask for
This table maps each piece of evidence an assessor, authorizing official or records officer is likely to request to the component that produces it. Read it as a checklist to set up before go-live, not after the first audit sample. DeployOpen prepares this evidence, but independent auditors and authorizing officials decide whether it is sufficient.
| Evidence | Produced by | What the reviewer checks |
|---|---|---|
| Authentication and permission configuration exports | Qdrant API keys and JWT collection permissions, or Milvus RBAC roles | Only named service and admin roles hold write or admin rights, and each collection's read and write grants match the agency access model |
| TLS configuration records | Qdrant REST and gRPC TLS settings, Milvus TLS settings, and the ingress or load balancer in front of them | Certificates are issued by an approved authority, protocols and cipher settings are recorded, and no plaintext listener remains reachable |
| JSON audit logs of authenticated operations | Qdrant audit logging (v1.17.0 and later), Milvus logs forwarded from the cluster | Logs record who ran which operation on which collection, are forwarded to the agency SIEM, and are retained for the period the agency schedule requires |
| Monthly vulnerability scan reports for CJIS scope | Scanner output covering the vector database hosts, container images and operating system, reviewed under control RA-5 | Scans run at least monthly, findings are triaged with owners and dates, and scope covers every host that holds or processes CJI |
| SP 800-53 control mapping for the chosen baseline | A control matrix built from the low, moderate or high baseline selected in SP 800-53B, linking each control to configuration, logs and procedures | Every selected control has a named owner, an implementation statement and a pointer to evidence, and inherited controls from the hosting provider are identified |
| Backup and restore test records | Qdrant snapshots or Milvus backup output, with dated restore tests on a separate environment | Restores were tested, the restored collection was queried and counted against the source, and the restored version matched the source version |
| Deletion logs showing source-linked vector removal | Application logs mapping each source record identifier to deleted point IDs, plus dated deletion events in the audit log | Removed records no longer return from search, and the process also addresses snapshots and backups that still hold the vectors |
| Records retention schedule applied to derived data | Agency retention schedule extended to embeddings, chunks, payloads and index metadata, with disposal triggers tied to source records | Each derived data class has a retention period and disposal method, and the schedule is approved by the records officer |
| AI feature logs, where the agency uses AI features | Gateway or application logs for embedding and query calls, and tracing data from any generative component | Confirm with counsel whether EU AI Act logging duties (Article 12 and Article 19) apply to the agency before setting retention periods |
What agencies ask before hiring a vector database implementation partner
How much does a government vector database implementation cost, and what drives it?
The cost depends mostly on the scope of the authorization boundary, the number of collections and source systems, the classification work on embedded content, accessibility testing for any user-facing interface, and the evidence the agency must produce. No price list applies. DeployOpen works from a written scope, and a quote follows from that scope. Ask any partner to itemize boundary design, infrastructure build, identity provider integration, classification and retention rules, accessibility testing, documentation and handover, so you can compare proposals line by line. Ask which items you would pay for separately, such as licensed infrastructure, staff time from your own records and security teams, or third-party assessment work.
Which costs are one-time and which recur after go-live?
One-time costs usually include design, the initial build, integration with the identity provider, initial data loading and re-embedding, classification and retention design, testing and the first evidence package. Recurring costs include the infrastructure that runs the cluster, backups and storage growth, patching and upgrades, monitoring, vulnerability scanning, access reviews, and any retainer for ongoing support. Ask the partner to separate both groups in the quote and to state who holds the cloud or data center accounts after handover. Recurring costs also grow with vector count and dimensions because memory and disk needs rise with both. Qdrant's documentation notes that a replication factor of 2 doubles storage, so replication choices feed directly into recurring cost.
How long does a public sector deployment take, and why does authorization set the pace?
The duration depends on how long the agency's authorization steps take, not only on technical build time. Build work can be scoped in writing, but the authorizing official must accept the boundary, the risk decisions and the control evidence before records are loaded. Ask the partner for a schedule with named gates, including design sign-off, environment hardening, security testing, authorization submission and records onboarding. Treat any timeline offered before the boundary and data types are defined as a planning guess. Also ask what happens if an assessor requests changes late in the process.
What does the agency have to supply before the work starts?
Three inputs usually block progress. First, access to the agency identity provider, including test accounts, group structures and the protocol configuration needed for single sign-on and per-collection permissions. Second, records owners who can state which collections exist, what each contains, its classification and its retention schedule. Third, an authorizing official who will own the risk decision for the system. Ask the partner to publish a dependency list at the start of the engagement, with an owner and a due date for each input. Missing records owners are the most common cause of rework in classification and retention, so ask how the partner will handle collections with unclear ownership.
Can our own staff run the vector database after handover, and what on-call skills are needed?
Often yes for a single-node or small Standalone-style deployment, but only if the team has the skills to run it. Self-hosted Qdrant needs block-level storage with a POSIX-compatible file system, not NFS or S3, and it ships without authentication by default, so the team must know how to configure API keys, TLS and JWT-based access. A distributed cluster uses Raft consensus and sharding, and Qdrant's documentation recommends at least three nodes for production so quorum survives a node failure. On-call staff need Kubernetes or VM operations, storage troubleshooting, backup and restore testing, and the ability to read audit logs. Ask the partner for a written skills matrix and a runbook you can test before go-live.
Does FedRAMP apply to a vector database we host ourselves?
FedRAMP scope turns on whether a cloud product or service creates, collects, processes, stores or maintains federal information on behalf of an agency, and on whether it is offered as a shared service. Under the scope described in OMB memo M-24-15, systems used only for a single agency's operations on cloud infrastructure and not offered as a shared service are out of scope. A deployment in your own data center is not a cloud service in the same sense, so FedRAMP may not be the governing requirement, but the agency still has to apply its own authorization and control baseline, such as NIST SP 800-53. Ask counsel and your authorizing official to confirm the classification of your deployment, and ask the partner to document how the boundary was reasoned. DeployOpen does not certify or authorize systems.
How do we handle re-embedding when the embedding model changes?
Changing the embedding model usually means new vectors for every chunk, because vectors from different models are not comparable. Plan for a parallel collection, re-embedding in batches, validation of search quality on a fixed test set, and a cutover with a rollback path. Keep the old collection and its snapshots until the cutover is accepted, and remember that retention rules apply to the derived vectors as well as the source records. Ask the partner how they version collections and embedding models, where the re-embedding job runs, which logs prove what was processed, and how the old vectors are deleted once retention allows. Confirm that the new model is also approved under your boundary before it touches records.
What compliance evidence should the partner deliver for the vector database?
A useful package maps each control to a configuration, a test and an owner. Expect items such as the boundary diagram, the authentication and per-collection access configuration, TLS settings for REST and gRPC, audit logging of authenticated API operations, backup and restore test records, vulnerability scan results and remediation history, and the classification and retention rules applied to embedded content. For CJIS-scoped data, the CJIS Security Policy version 6.1 calls for FIPS 140-3 certified modules or AES with keys of at least 256 bits and monthly vulnerability scanning, so ask how the partner will verify those settings. DeployOpen prepares these artifacts for your assessors, but the assessors and authorizing officials make the final judgments.
Questions to put to a partner before signing a government scope
Start with the boundary, because every other answer depends on it. Ask the partner to name, in writing, every host, network segment, cloud account or data center where the vector store, its object storage, its metadata service and its embedding pipeline will run, and who holds administrative access to each one. Then ask whether any component, including the embedding model, a monitoring agent, a container registry or a licensing check, will call an external service at runtime or during installation. A vague answer such as "fully on premises" is not enough. Expect a diagram with named boundaries and a list of outbound connections that the agency's security team can test with its own tools. If the partner proposes a managed service for records that include controlled or criminal justice information, ask for written evidence that the specific service is authorized for that data category at the required level, not a general statement about the vendor's compliance program.
Next, ask how the day-one configuration is secured. Qdrant's security documentation states that self-deployed instances listen on all network interfaces and have no authentication configured by default, so a partner who installs with defaults has not finished the job. Ask which API keys are issued (admin and read-only), how TLS is enforced for REST and gRPC, how per-collection read and write permissions are granted through JWT-based access control, and how audit logging of authenticated operations is shipped to the agency's logging system. Ask how the agency identity provider is connected and who maps groups to collection permissions. On sizing, ask for the memory and block storage calculation for the agreed vector count and dimensions, and confirm that the storage is block-level with a POSIX-compatible file system rather than NFS or S3, because the Qdrant installation documentation says it cannot run on those. Finally, ask how restores and deletion are proven. Request the restore test record, including the snapshot version, the target Qdrant release and the date the restore was validated. Ask how a deletion request for a case file propagates to vectors, payloads, snapshots and backups, and what evidence shows that it happened. Ask which NIST SP 800-53 baseline and which controls the partner maps to, and whether the mapping is delivered as machine-readable profiles. A partner that cannot produce restore records, or that treats snapshots as outside deletion scope, should not be signed for a government workload.
How DeployOpen scopes and supports public sector vector search
This sequence shows how an agency or public body moves from a written scope to a hardened, documented and supported vector search service that runs inside its own government boundary. Each step ends with an output the agency can check before the next one starts.
Agree the scope and boundary in writing
DeployOpen and the agency define which record sets, case files and document types are in scope, which environment will host the service, and which parties may administer it. The agency's security, records and legal contacts sign off on the boundary before any work starts. Engagements are fixed-scope, so deliverables, responsibilities and exclusions are written down in the agreement. The output is a signed scope statement that names the data classes, hosting location and owners of each decision, and it is the reference for every later step.
Confirm hosting and compliance obligations
Before choosing a deployment pattern, the agency confirms which federal, state or local frameworks apply, such as NIST SP 800-53 baselines, CJIS Security Policy, CUI handling rules or accessibility requirements for any user-facing portal. DeployOpen maps those obligations to the hosting model, so the team can see whether the platform sits in an authorized cloud, an agency data center or an air-gapped network. Where a framework needs an authorization decision, the agency's authorizing official and independent assessors make that decision, not DeployOpen. The output is a control map that lists each obligation, its owner and the evidence it needs.
Classify embedded content and retention rules
The agency's records officers and data owners classify the source documents and the chunks, embeddings and metadata derived from them, then state how long each derived set is kept and when it must be deleted. DeployOpen works with those owners to set collection boundaries, payload fields and deletion workflows that follow the source record lifecycle. The output is a classification register and a retention schedule for derived data, including how snapshots and backups are treated, reviewed by the records owner before ingestion begins.
Design access control tied to the identity provider
DeployOpen designs how agency identities from the existing identity provider map to vector database roles, using admin, read-only and per-collection permissions where the chosen engine supports them. Qdrant documents admin and read-only API keys, TLS and JWT-based per-collection permissions, and Milvus documents authentication, TLS and role-based access control. The team confirms which of these features the selected engine and version provide in the agency's environment before relying on them. The output is an access design with a role matrix, a list of service accounts and a test plan proving that users only retrieve results from collections they are entitled to see.
Build, harden and integrate the platform
DeployOpen installs the chosen open-source engine in the agency's infrastructure, closes default exposure such as open network interfaces and missing authentication, enables TLS and audit logging, and connects the embedding pipeline and application layer. Qdrant's security documentation states that self-deployed instances are not secure by default, so hardening is a required step rather than an option. Storage is placed on block devices that meet the engine's requirements. The output is a hardened build record with configuration files, a list of enabled controls and a test report for the settings the agency signed off.
Test restores, deletion and monitoring
DeployOpen runs security testing against the deployment, then tests backup and restore, version-matched snapshot restores and the deletion workflow for source records, so the agency can see what a restored or deleted vector set actually contains. Monitoring and alerting are configured for availability, failed authentication and administrative actions. The output is a test record that shows each restore completed, each deletion was verified in live collections and backups, and each monitoring alert fired as designed.
Document evidence for assessments
DeployOpen assembles the configuration baselines, access matrices, retention schedules, logs, test results and runbooks that the agency's assessors will request. DeployOpen prepares this evidence and explains what it shows, but it does not issue audit reports, attestations or certifications; the agency's independent assessors and authorizing officials make those determinations. The output is an evidence package indexed to the control map from the second step, so each control has a named artifact and an owner.
Hand over and support under a retainer
After handover, the agency's operations team runs the platform with DeployOpen's runbooks, and any ongoing support, upgrades and continuous testing are covered by a retainer agreed in writing. Upgrades are planned against the engine's release notes and tested in a non-production copy before they reach agency records. The output is a signed handover with the runbooks, an agreed support scope and a schedule for periodic security testing, reviewed each time the scope changes.
