Trust center
The evidence, not the conclusion.
A certification is a conclusion someone else has signed. We do not hold one, so this page publishes the underlying evidence instead: the controls running in production, the ones still to build, the carve-outs on every commitment, and the dates we are working to. All of it is checkable, which a badge is not.
Disclosure
We publish our current audit status rather than a row of badges. Seldon holds no third-party certifications, attestations, or authorizations today, and nothing on this page should be read as an audit result. The security controls marked as implemented are running in production and we can walk you through the mechanism. Everything in the compliance roadmap is a target date with the work stated, not a credential we hold. Reports are available under NDA once they are issued, and this page will say so on the day that changes; until then we would rather show you the architecture than a badge.
Running in production today, alongside 9 compliance frameworks tracked below. Each control is listed with the mechanism behind it and the point at which the claim stops.
01Compliance roadmap
Target dates with the work stated, not credentials we hold
Read the scope column before the status column. SOC 2 is an attestation issued by a CPA firm, ISO is an accredited certification of a management system, HIPAA has no certification at all, and GDPR, CCPA and the EU AI Act are law rather than credentials. Those are four different kinds of thing, and a vendor that flattens them into one row of logos is telling you nothing.
SOC 2 Type II
In progressWhat it would actually certify
An independent CPA firm's attestation under AICPA SSAE 18 that stated controls were both suitably designed and operating effectively across an observation period. It is an attestation report, not a certification, and no registry of it exists. Our intended scope is the Security, Availability, and Confidentiality trust services criteria, which is the scope pattern used by the established API vendors.
Timeline
Control implementation and evidence collection underway. Target: readiness assessment Q4 2026, six month observation window opening Q1 2027, first report Q3 2027. No SOC 2 report exists today and we will not offer one under NDA until it does.
Controls we implement today
- Documented information security, access control, and incident response policies
- Centralised audit logging of control plane and inference plane events
- Change management with peer review and recorded approvals on production deploys
- Quarterly access reviews against a single identity provider
- Vulnerability scanning in CI and an annual third party penetration test
ISO/IEC 27001:2022
PlannedWhat it would actually certify
Accredited certification of an information security management system against ISO/IEC 27001:2022, Edition 3, covering 93 Annex A controls across organisational, people, physical, and technological themes. The certificate covers the management system inside a stated scope boundary, not any individual product feature. ISO/IEC 27017:2015 and ISO/IEC 27018:2025 are codes of practice and are not separately certifiable; the correct construction is to reference their controls in the Statement of Applicability, which is what we intend to do.
Timeline
Sequenced after SOC 2 so it can reuse the same evidence base, which overlaps by roughly 70 percent. Target Stage 1 in Q3 2027 and certificate issuance in Q1 2028. Not certified today.
Controls we implement today
- Asset and data inventory maintained as code alongside the infrastructure it describes
- Risk register with named owners and reviewed remediation dates
- Supplier and sub-processor review before any vendor touches customer data
- Business continuity and disaster recovery runbooks exercised on a schedule
- Secure development lifecycle covering secret handling, dependency review, and secure coding
ISO/IEC 42001:2023
PlannedWhat it would actually certify
Accredited certification of an artificial intelligence management system against ISO/IEC 42001:2023, Edition 1, published December 2023. It certifies how an organisation governs the AI it develops, provides, and operates: impact assessment, data governance, model lifecycle, and human oversight. It does not certify model accuracy, model safety, or conformity with the EU AI Act, and no regulation currently mandates it.
Timeline
Runs roughly three to six months once ISO/IEC 27001 is in place, because clauses 4 to 10 are shared. Target certificate in H2 2028. Not certified today.
Controls we implement today
- Model inventory recording provenance, licence, and upstream provider for every served model
- Documented evaluation and regression process before a model version is promoted
- Human oversight and rollback path for every automated serving decision
- AI impact assessment recorded per model family rather than per deployment
HIPAA
In progressWhat it would actually certify
There is no HIPAA certification, seal, or registry. The HHS Office for Civil Rights does not pre-clear or endorse any product, so any vendor displaying a HIPAA badge is publishing a self-assessment. What a vendor can genuinely offer is a Business Associate Agreement carrying the required elements at 45 CFR 164.504(e), and the technical safeguards at 45 CFR 164.312: audit controls, unique user identification, access management, and defined retention and disposal.
Timeline
The PHI-safe logging path is built and the BAA template is in counsel review. We describe this as a HIPAA-ready path with a BAA available, never as HIPAA certified or HIPAA compliant, because neither status exists. We sign a BAA where the controls behind it are demonstrable for the workload in question, and decline where they are not.
Controls we implement today
- Zero retention serving path so prompts and completions are not written to durable storage
- Prompt and completion contents excluded from application and request logs by default
- Unique per-principal identity with no shared service credentials in the data path
- Training on customer content prohibited by design, which is the use a BAA cannot authorise
- Sub-processor obligations drafted to flow down unchanged, since the chain must be unbroken
GDPR
In progressWhat it would actually certify
A regulation, not a certification, so there is nothing to hold. A processor's posture is contractual: an Article 28 data processing agreement, Standard Contractual Clauses under Implementing Decision (EU) 2021/914 (Module 2 for customer to Seldon, Module 3 for Seldon to sub-processors), a published sub-processor register, and a transfer impact assessment under Clause 14. Article 28(10) is the clause that matters most for an inference vendor: a processor that decides the purposes of processing, for example by training on customer content without instruction, becomes a controller.
Timeline
An Article 28 data processing agreement and SCC annexes are executed with customers under agreement today. The public versions and the sub-processor register are in counsel review before publication, and the register is provided on request in the meantime. A transfer impact assessment with concrete technical measures, rather than an executive summary, follows the first EU region.
Controls we implement today
- Processing on documented customer instruction only, with training on customer content excluded contractually and architecturally
- Deletion and return of customer data at end of service, including derived copies
- Sub-processor register naming each vendor, its region, its transfer mechanism, and its retention
- Data subject request handling routed through the customer as controller
- Breach notification path with defined internal escalation timings
CCPA / CPRA
In progressWhat it would actually certify
California statute plus California Privacy Protection Agency regulations, not a certification. For an inference vendor the operative posture is a service provider addendum restricting use of personal information to the customer's documented business purposes, plus support for deletion, access, and opt-out requests. The CPPA's 2025 regulations package took effect 1 January 2026; risk assessments are already required, and automated decisionmaking technology obligations reach customers who use inference in hiring, lending, or insurance decisions on 1 January 2027.
Timeline
Service provider restrictions are carried in the customer agreement today; the standalone addendum is in counsel review before publication. Documentation supporting customer ADMT obligations is targeted ahead of their 1 January 2027 compliance date, since that requirement lands on them and they will push it down to us.
Controls we implement today
- No sale or sharing of personal information, and no cross-context behavioural advertising, at any tier
- Personal information used only for the customer's documented purposes, with no secondary use
- Deletion propagated to backups and derived stores on a defined schedule
- Retention windows documented per data category rather than set globally
PCI DSS
PlannedWhat it would actually certify
Validation against PCI DSS v4.0.1, the only active version since v4.0 retired on 31 December 2024, for systems that store, process, or transmit cardholder data. Evidenced by an Attestation of Compliance, not a certificate. It is largely irrelevant to inference: cardholder data belongs to the payment processor, and no inference vendor we surveyed holds it.
Timeline
Not on the roadmap. Card data is handled entirely by our payment processor and does not reach Seldon systems, which keeps us out of scope. If we ever build payment functionality into the product we would pursue narrowly scoped validation, state the exact scope here, and not imply anything broader.
Controls we implement today
- Payment flow delegated to a PCI validated processor, keeping cardholder data out of our environment
- Cardholder data never accepted through the inference API or stored in our systems
- Annual confirmation that the scope boundary still holds
FedRAMP
PlannedWhat it would actually certify
A United States federal authorization to operate, granted through a sponsoring agency, not a commercial certification and not transferable to private sector assurance. FedRAMP 20x replaces point-in-time Rev 5 audits with continuously validated Key Security Indicators; Class C covers Moderate impact, which is the level most federal workloads require. Nothing moves without a federal agency sponsor committed in writing.
Timeline
Not on the roadmap without a federal pipeline and a sponsoring agency. The FedRAMP 20x public submission pipeline opened in FY26 Q4, and a Class C submission is the path we would take rather than legacy Rev 5, whose new agency authorizations stop at the end of FY27. We are not listed on the FedRAMP Marketplace and do not describe ourselves as FedRAMP ready.
Controls we implement today
- FIPS validated cryptographic modules available on the encryption path
- Machine readable control evidence emitted from infrastructure as code, which is the direction 20x assumes
- Continuous vulnerability scanning with tracked remediation deadlines
EU AI Act
In progressWhat it would actually certify
Law rather than a credential; there is no conformity mark for a general purpose inference API and no body that certifies one. Article 50 transparency obligations apply from 2 August 2026 and were not delayed by the Digital Omnibus. General purpose AI model provider obligations under Articles 51 to 56 sit with whoever develops and places a model on the market, which for third party open weights models is the upstream developer rather than Seldon. High risk obligations were moved to 2 December 2027 for standalone Annex III systems and 2 August 2028 for embedded Annex I systems.
Timeline
Article 50 disclosure is applied in our own conversational surfaces, and a GPAI provenance record is carried for every model we serve. Delayed high risk obligations are tracked but do not apply to us as an infrastructure provider today. We do not claim EU AI Act conformity, because for our role there is nothing to be assessed against.
Controls we implement today
- Per-model provenance record naming the upstream provider and its stated GPAI position
- AI interaction disclosed at the start of any Seldon operated conversational surface
- Model documentation passed through to customers so they can meet their own deployer obligations
- Licence and acceptable use terms tracked per open weights model we serve
The controls listed against each framework are work we do ourselves and can demonstrate on a call. They are not audit findings: no report has been issued for any framework here. Buyers verify claimed credentials against IAF CertSearch, the ANAB directory, and the FedRAMP Marketplace, all of which are public and none of which list us.
02Security controls
What is built, what is not, and where each claim stops
TLS 1.3, AES-256, tenant scoped KV cache, audit logs, quarterly access reviews. Evidence of this kind is more useful to a reviewer than any adjective, and it is checkable. 14 of the 26 controls below are built today; the remaining 12 say roadmap, because a security review that finds a listed control missing costs more than never listing it.
Data handling
What happens to a prompt after it leaves your process, and what does not happen to it.
2 of 5 built
No training on customer data
ImplementedCustomer prompts, completions, and uploaded content are never used to train, fine-tune, or evaluate any model, ours or an upstream provider's. This is enforced by the serving architecture rather than by policy alone: inference traffic does not reach any training data path.
Caveat
Aggregate operational metrics such as token counts, latency, and error rates are collected. They contain no prompt or completion content.
Zero data retention on synchronous inference
ImplementedPrompts and completions on synchronous endpoints are held in memory for the life of the request and are not written to durable storage.
Caveat
Zero retention is never total, and vendors who claim otherwise are rounding. Abuse classifier scores, which contain no prompt text, are retained to enforce acceptable use. Asynchronous and batch endpoints must buffer inputs until the job completes, and are excluded from the zero retention path by construction rather than by exception.
Configurable retention windows
RoadmapWhere retention is deliberately enabled, for example to power request history or replay, the window is set per project and enforced server side rather than trusted to the caller.
PII detection and redaction
RoadmapOptional detection and masking of personal information in prompts and completions before they reach any log or downstream store.
Caveat
PII detection is probabilistic and context dependent, so it degrades on short inputs and cannot be treated as a guarantee. No vendor in this market publishes precision or recall figures, and we will not invent them. We are building redaction to cover the log path as well as the response, because the common industry failure is masking the response while the raw value still lands in invocation logs.
Deletion on request
RoadmapAccount and project deletion removes stored content from primary stores immediately and from backups within the documented backup rotation.
Tenant isolation
Whether another customer's workload can observe, contend with, or leak into yours.
2 of 4 built
No GPU sharing across tenants
ImplementedA physical GPU serves one tenant's requests at a time. Tenants are separated at the device boundary rather than by process isolation inside a shared device.
KV cache is memory resident and tenant scoped
ImplementedThe attention KV cache lives in GPU memory, is scoped to a single tenant, and is never persisted to disk. Prefix cache entries are keyed per tenant, so a cache hit cannot be served across an account boundary.
Single tenant clusters
RoadmapDedicated capacity with no shared control plane or data plane components, for customers whose threat model excludes multi-tenancy entirely.
Confidential computing
RoadmapInference inside a hardware trusted execution environment on Hopper or Blackwell GPUs with attested boot, so that neither the host nor the operator can read prompts in memory.
Caveat
The honest performance picture, from the only independent published benchmark: throughput overhead is under 7 percent for typical queries and close to zero for large models and long sequences, because the cost is PCIe data transfer rather than compute. Time to first token is a different story, at roughly 19 to 26 percent on small models with short prompts. It is a latency tax on chatty small model workloads and a rounding error on large batch workloads.
Encryption and key management
How data is protected in transit, at rest, and who holds the keys.
2 of 4 built
Encryption in transit
ImplementedTLS 1.3 on all external endpoints with TLS 1.2 as the floor. Internal service to service traffic is encrypted and does not traverse the public internet.
Check it yourself: Observable directly from any client handshake.
Encryption at rest
ImplementedAES-256 on all persistent stores, including object storage, databases, and model weight caches.
Customer managed keys (BYOK)
RoadmapEnvelope encryption with a customer controlled key encryption key, so that revoking the key renders stored content unreadable.
Caveat
BYOK is envelope encryption with a customer held KEK. It is not customer exclusive custody, and we will not describe it that way; a platform managed key remains in the chain to guarantee baseline encryption. Buyers who read BYOK as 'the vendor cannot decrypt' are misreading it, at every vendor.
FIPS validated modules
RoadmapFIPS 140-3 validated cryptographic modules available on request for regulated workloads.
Network and deployment topology
Where inference runs and what network boundary it sits behind.
2 of 4 built
Network segmentation
ImplementedDefault deny between workload namespaces, enforced by container network policy, so a compromised serving pod cannot reach another tenant's or the control plane's network surface.
Region pinned inference
ImplementedRequests are pinned to a named region so that processing location, not only storage location, is under customer control.
Caveat
Region pinning currently covers United States regions. Additional regions are listed under data residency below, with their target dates. Cross-region routing for capacity reasons is off unless a customer enables it, because the common industry trap is retained data landing in the destination region rather than the calling region.
Private connectivity
RoadmapPrivate endpoints and VPC peering so that inference traffic never traverses the public internet.
In-VPC and on-premises deployment
RoadmapThe serving stack deployed into the customer's own cloud account or datacentre, with weights and traffic never leaving their boundary.
Model and content safety
Controls on what the model is asked to do and what it is allowed to return.
3 of 4 built
Model provenance record
ImplementedEvery served model carries a record of its upstream provider, licence, weight checksum, and quantisation, so a customer can answer supply chain questions about what actually served their request.
Abuse monitoring
ImplementedAutomated classification of traffic against the acceptable use policy, retaining classifier scores rather than prompt content.
Caveat
Classifier scores are retained even under zero data retention, because they are what makes the policy enforceable. They do not contain prompt or completion text.
Configurable input and output guardrails
RoadmapOptional content filters, denied topic lists, and prompt injection detection applied at the API boundary, callable independently of a model invocation.
No human review of customer content
ImplementedNo Seldon employee reads prompts or completions. Access to any environment where content could be observed requires a break glass procedure with recorded justification and time bounded approval.
Caveat
Break glass access exists for incident response and cannot be removed without making outages unrecoverable. Every use is logged and surfaced to the affected customer.
Access control and auditability
Who can act on your account, and whether you can prove what they did.
3 of 5 built
Role based access control
ImplementedOrganisation, project, and key scoped roles, so that an API key can be limited to a single project and a single set of models.
Audit logging
ImplementedControl plane events, including key creation, permission changes, and deployment changes, are logged with actor, timestamp, and source address, and are exportable.
Caveat
Audit logs record metadata about requests. They do not record prompt or completion content, which is deliberate and is what keeps the log itself out of scope for a BAA.
SSO via SAML and OIDC
RoadmapFederated sign-in against the customer's identity provider, with enforced session policy.
SCIM provisioning
RoadmapAutomated user provisioning and deprovisioning, so that removing someone from the directory removes their access here.
Key lifecycle controls
ImplementedAPI keys carry expiry dates, last used timestamps, and scoped permissions, and can be revoked without redeploying anything.
03Data handling
Every commitment, with its carve-outs attached
A zero retention claim with its exceptions stated reads as more credible than a flat one, and it is the version that survives a security questionnaire. A commitment with no stated exceptions is either trivial or untrue, so the carve-outs below are printed at the same weight as the commitments they qualify.
Training use
In effect todayWe commit never to train on customer content, and we do not make this configurable.
Prompts, completions, attachments, and embeddings are excluded from every training and evaluation pipeline. There is no opt-in that reverses this, because an opt-in would create the ambiguity the commitment exists to remove. For an inference vendor this is also a legal position rather than a courtesy: under GDPR Article 28(10), a processor that decides to train on customer data has determined the purposes of processing and becomes a controller.
Carve-outs (1)
- Aggregate operational telemetry such as token counts, latency percentiles, and error rates, none of which contain content.
Retention
In effect todayOur commitment is zero retention by default on synchronous inference, with every carve-out published rather than buried.
Prompts and completions on synchronous endpoints exist in memory for the life of the request. Nothing is written to durable storage unless a customer explicitly enables a feature that requires it, and enabling such a feature is a visible account level action rather than a per-request flag we might silently honour. Where retention is enabled, the default window is 30 days, which is where the market has converged.
Carve-outs (3)
- Abuse classifier scores are retained to enforce acceptable use. They contain no prompt or completion text.
- Asynchronous and batch jobs buffer inputs until the job completes, then delete them.
- Features that are stateful by definition, such as stored conversation history, retain by design. We will label these clearly rather than let a customer discover it in an incident.
Sub-processors
In effect todayWe maintain a complete sub-processor register and give 30 days notice before adding one that touches customer data.
The register names each sub-processor, the purpose, the categories of data involved, the hosting region, and the transfer mechanism. It is current, and we send it on request to anyone running a vendor review; the public page carrying it is in counsel review before publication, which is a publishing step rather than a gap in the register. Obligations flow down unchanged by written contract, which is required under GDPR Article 28(4) and under HIPAA where a BAA is in force. We remain fully liable for our sub-processors, so the register is a statement of our own risk as much as a disclosure.
Carve-outs (1)
- Emergency replacement of a failed sub-processor may compress the notice period. We notify at the point of change and explain why.
Region residency
In effect todayWe commit to pinning both processing and storage to a customer selected region, not storage alone.
Processing location is the part vendors quietly leave floating: a request stored in your region may still have been executed elsewhere for capacity reasons, and any retained data then lands in the destination region. Region pinning here covers where inference actually runs. Cross-region routing is off unless a customer turns it on, and the trade is stated plainly at that point.
Carve-outs (1)
- United States regions are serving traffic today. European Union regions are next, and further regions after that. We list a region as available only once it is serving traffic, so this line is a shorter list than our roadmap.
Deletion and return
In effect, run by handWe commit to deleting or returning all customer data at the end of the service relationship, including derived copies.
This is the GDPR Article 28(3)(g) obligation and we treat it as the default rather than as a negotiated term. Deletion covers primary stores immediately and backup media within the documented rotation, and derived artifacts such as cached embeddings are enumerated rather than assumed away. It is run by our team against a written checklist rather than triggered from a console, so it carries a response time; self-serve deletion is listed as roadmap in the controls above rather than implied here.
Carve-outs (2)
- Records we are legally required to keep, such as billing records, are retained for the statutory period and contain no customer content.
- Backup media are overwritten on rotation rather than selectively edited, so deletion from backups completes at the end of the rotation window rather than instantly.
Human access
In effect todayWe commit that no employee reads customer prompts or completions in the ordinary course of operating the service.
There is no content review queue and no annotation workflow. Access to environments where content could be observed requires break glass approval, is time bounded, and is logged.
Carve-outs (2)
- Break glass access during incident response, which is logged and disclosed to the affected customer.
- Where a customer explicitly shares a prompt with support to debug it.
04Availability
A target we publish is not a guarantee you can enforce
Presenting an operational target as a contractual guarantee is the failure mode this page exists to avoid, so each tier states which one it is. The measurement basis matters more than the headline number and is stated first, because that is where most published availability commitments quietly do their work.
How we measure it
Measured at inference completion rather than at the load balancer: a request that reaches our gateway and then fails on the GPU counts as downtime. An error is any request that fails for a Seldon caused reason, which includes throttling and timeouts, not only HTTP 500. The denominator is calendar minutes rather than transaction counts, so a low traffic outage window is still visible. Client cancellations, invalid requests, authentication failures, and traffic above purchased capacity are excluded.
Every figure on a non-contractual tier is an operational target we publish so it can be checked against our status page. No service credits attach to it, and we would rather say that than let it be discovered during an incident.
Free
Evaluation and prototyping.
Uptime
Published so it can be checked against our status page. No service credits attach, and no remedy is implied.
- Failure domain
- None. Shared capacity with dynamic rate limits, served on a best effort basis.
- Service credits
- None. No remedy attaches to a target.
Support response targets
- AllAny issue.
- Community forum and documentation. No response target.
First human response, not resolution. Vendors who publish a single support number are usually quoting this one.
We publish no uptime or latency target here, and we would rather say that than imply one. Multi-tenant shared capacity cannot carry a meaningful availability commitment, which is the same position the established serverless inference vendors take.
Standard
Production workloads on shared capacity.
Uptime target
Published so it can be checked against our status page. No service credits attach, and no remedy is implied.
- Failure domain
- Node level: GPU faults, driver crashes, and thermal events, absorbed by health checking and fast replica replacement within a single facility.
- Monthly downtime budget
- 3 hours 36 minutes
- Service credits
- None. No remedy attaches to a target.
Support response targets
- P1Service unusable in production.
- 4 business hours
- P2Degraded performance or a feature unavailable.
- 1 business day
- P3Question or minor issue.
- 2 business days
First human response, not resolution. Vendors who publish a single support number are usually quoting this one.
An operational target, not a contractual guarantee, and no service credits attach. We publish it so the number can be checked against our status page rather than to imply a remedy that does not exist.
Business
Teams running customer facing products on Seldon.
Uptime target
Published so it can be checked against our status page. No service credits attach, and no remedy is implied.
- Failure domain
- Datacentre level: weights deployed across two facilities with enough capacity on each side to absorb full load, and live traffic to both. Not a cold standby.
- Monthly downtime budget
- 43 minutes 12 seconds
- Latency target
- Per model output token rate target, stated as p95 rather than p50. The market convention is a p50 target measured per five minute window, which is a much weaker promise than most buyers read it as; we would rather publish the harder number.
- Service credits
- None. No remedy attaches to a target.
Support response targets
- P1Service unusable in production.
- 1 hour, 24 hours a day
- P2Degraded performance or a feature unavailable.
- 4 business hours
- P3Question or minor issue.
- 1 business day
First human response, not resolution. Vendors who publish a single support number are usually quoting this one.
99.9% is the published ceiling across every inference vendor surveyed, so treat any higher self-serve number in this market with suspicion. This target becomes contractual, with service credits, under a signed agreement.
Enterprise
Regulated and high volume workloads under a negotiated agreement.
Uptime target
These figures are what an enterprise agreement contains and are the basis we negotiate from. They are not in force until it is signed.
- Failure domain
- Datacentre level as standard. Regional survivability at 99.99% requires reserved failover capacity sitting idle in a second region, which is a capacity purchase rather than a routing configuration, and is priced as one.
- Monthly downtime budget
- 43 minutes 12 seconds at 99.9%, 4 minutes 19 seconds at 99.99%
- Latency target
- Per model throughput and time to first token targets, defined in the agreement with the measurement window stated explicitly.
- Service credits
- Tiered service credits against future charges, defined in the agreement. Credits are the customary remedy across this market and are typically capped as a percentage of monthly fees; we will state our cap in the agreement rather than leave it to be discovered.
Support response targets
- P1Service unusable in production.
- 15 minutes, 24 hours a day, with a named on-call escalation path
- P2Degraded performance or a feature unavailable.
- 1 hour
- P3Question or minor issue.
- 4 business hours
First human response, not resolution. Vendors who publish a single support number are usually quoting this one.
These figures are what an enterprise agreement contains and are the basis we negotiate from. They are not in force for any given customer until that agreement is signed, and the availability target is fixed per region and workload shape in the agreement rather than assumed uniform across the fleet.
05Security contact
Reaching the security team, and what we can send you
One address, read by the engineers who built the controls above rather than by a sales team routing to them. We answer questionnaires directly, including the questions where the honest answer is that the control is on the roadmap.
Security team
security@seldon.aiVulnerability reports, questionnaire responses, architecture review requests, and documentation requests all go here. Please include the deployment shape you are evaluating, since the answers differ between shared, region pinned, and dedicated capacity.
What we can provide today
- A written walkthrough of every control marked implemented above, with the mechanism described rather than asserted
- Your own security questionnaire, answered row by row against the same statuses published here
- An architecture review call covering tenant isolation, the retention path, key handling, and the audit log schema
- The current sub-processor register, named entity by entity with the region and transfer mechanism for each, sent on request while the public page carrying it is in counsel review
- The acceptable use policy and the abuse monitoring behaviour that enforces it
What we cannot provide yet
- A SOC 2 report. The observation window has not opened, so no report exists to send.
- An ISO/IEC 27001 or 42001 certificate. Neither has been issued.
- A Business Associate Agreement signed on the spot. The PHI-safe logging path is built and the template is in counsel review, and we sign per workload once the controls behind it are demonstrable for that workload.
- A FedRAMP authorization or a Marketplace listing. Neither exists and neither is on the roadmap without a sponsoring agency.
- Service credits on any tier below Enterprise. The availability figures on the other tiers are operational targets with no remedy attached, and we will not write one into a page instead of a contract.
We will publish each of these here on the day it exists, and hand it over under NDA on request. Until then, asking us for one will get you a straight no rather than a document that does not survive checking.
Send us your security questionnaire.
We will answer it directly, in your format, including the rows where the answer is that the control is on the roadmap and the date we expect it. If you would rather see the mechanism than read about it, we will walk an engineer of yours through the isolation boundary, the retention path, and the audit log schema on a call.