Trust centre
DocumentMSトラストセンター
This trust centre sets out how DocumentMS protects your documents: encryption at rest and in transit, key management, the hosting regions available, backup and recovery targets, penetration testing cadence, our sub-processor list, and how we handle vulnerability reports and security incidents.
Compliance status
ISO/IEC 27001
Controls are implemented and evidenced against the Annex A set, and internal audit runs annually. DocumentMS is not certified, and we say so rather than implying otherwise. The control documentation and our gap assessment go out under NDA on request.
SOC 2 Type II
No Type II report has been issued yet. The Security and Confidentiality criteria are implemented and monitored internally, and we will share the control matrix and our readiness position under NDA so a reviewer can assess the substance rather than wait for the certificate.
GDPR
DocumentMS acts as a processor on your documented instructions. The data processing addendum, sub-processor list and transfer mechanisms are published; the erasure and access-request tooling is described on the GDPR page.
HIPAA
We execute a business associate agreement before any protected health information is uploaded — request it from your account contact and it is signed as part of onboarding rather than after it. Without an executed BAA in place, the tenant is not configured for PHI.
Cyber Essentials
The five Cyber Essentials control areas — boundary firewalls, secure configuration, access control, malware protection and patch management — are implemented and reviewed quarterly. Certification is not currently held; tell us early if a UK public sector procurement requires it and we will schedule assessment against your timetable.
Sub-processors
The current list of third parties that process customer data on our behalf, what each does, where it operates and the transfer safeguard relied on.
Encryption and key management
Documents are encrypted at rest with 256-bit encryption and in transit over TLS. That much is straightforward and is table stakes; the question a security reviewer actually asks is who holds the keys.
Where you use the platform’s own storage, key management is ours and is described in the sub-processor list. Where you configure your own Amazon S3 bucket or Azure Blob Storage container — available on the Enterprise tier — encryption keys, bucket policy, object lock configuration and access logging remain in your account and under your control. For organisations with a sovereignty or key-custody requirement, that is usually the deciding capability, because it converts a vendor commitment into something you can verify yourself.
Concretely: AES-256-GCM at rest, TLS 1.2 and 1.3 in transit with TLS 1.0 and 1.1 disabled and only forward-secret cipher suites enabled, and HSTS with preload on every public hostname. Platform-held data encryption keys are rotated annually and on personnel change, wrapped by a key encryption key held in a hardware security module. Customer-managed keys are available on customer-provided S3 or Azure backends, where key custody is yours end to end; they are not available on platform-managed storage, and we would rather state that limit than describe it vaguely.
Hosting regions and data residency
| Storage backend | Where document bytes sit | Who controls the region | Availability |
|---|---|---|---|
| Platform-managed storage | One of eu-west-1 Ireland, eu-central-1 Frankfurt, us-east-1 N. Virginia, af-south-1 Cape Town or ap-southeast-1 Singapore, fixed at provisioning | DocumentMS, with region selection at provisioning | All tiers |
| Amazon S3 in your account | The bucket and region you nominate | You | Enterprise |
| Azure Blob Storage in your account | The container and region you nominate | You | Enterprise |
| Metadata, search index and audit trail | The platform region selected at provisioning, including where document bytes sit in your own bucket | DocumentMS | All tiers |
Backup, recovery and continuity
Three independent backup copies are maintained. The number is the least interesting part: a backup that has never been restored is a hypothesis, so restore testing is part of the operating routine rather than an annual exercise, and the results are recorded.
The commitments are a 15-minute recovery point objective and a 4-hour recovery time objective, both written into the contract rather than described as aspirations. Restores are tested quarterly against a realistic failure — a full tenant rebuild from backup, not a file-level spot check — and the result is recorded with the elapsed time. At least one copy is held in a region separate from the primary.
A commitment you cannot evidence is worse than no commitment, so ask us for the date and elapsed time of the most recent restore test. If a vendor cannot answer that from memory, the objective is a design target rather than a tested one.
Penetration testing and vulnerability management
An independent security firm tests the application, the API and the tenant isolation boundary annually, and again after any architectural change to authentication or storage. The scope covers authenticated and unauthenticated paths and explicitly includes cross-tenant access attempts. An executive summary, with the remediation status of every finding, is available to prospects and customers under NDA.
Vulnerabilities are remediated against published targets by severity: critical within 7 days, high within 30 days, medium within 90 days, and low at the next scheduled release. Dependencies are scanned on every build and the pipeline fails on a new critical or high advisory, so the targets apply from the day an advisory lands rather than from the day someone notices it.
We accept vulnerability reports through the contact in our security.txt file and undertake not to pursue researchers who act in good faith, stay within scope and give us reasonable time to remediate before disclosure.
Product security controls
- Role-based access control applied per module, with preview-only as a distinct level from preview-and-download
- Two-factor authentication using time-based one-time codes, enforceable per role
- OIDC single sign-on with Microsoft Entra ID, Okta and Google Workspace, so directory deactivation removes access
- Configurable password policy — length, complexity, rotation and reuse history
- IP allow-listing per user or role
- An append-only audit trail recording views and downloads, not editable by any role including administrators
- Administrator-only recycle bin, so deletion is recoverable but not reversible by the person who deleted
- Time-boxed break-glass access that raises an alert and is logged as a distinct event type
- Encrypted storage of credentials for connected systems
- Scoped API keys with per-key permissions, and signed webhook payloads
How we handle a security incident
Step 1: Detect and triage
An alert or report is assessed against a severity scale on a published clock: critical within 1 hour, high within 4 hours, medium within 1 business day. The clock starts when the alert fires, not when someone acknowledges it.
Step 2: Contain
Containment takes priority over investigation. Affected credentials are revoked, access paths closed, and the scope bounded before root cause analysis begins.
Step 3: Notify
Affected customers are notified without undue delay and in any event within 48 hours of us becoming aware, which is the window written into the data processing addendum. Notice goes to your named administrators and states what is known at the time rather than waiting for a complete picture.
Step 4: Remediate and report
A post-incident report covering timeline, root cause, remediation and preventive actions is provided to affected customers.
FAQ
Questions from security reviews
Can we run our own penetration test against the platform?
Yes, against a dedicated environment provisioned for the purpose, with 10 business days’ notice and agreed rules of engagement. We do not permit testing against production, because your test would be running against other tenants’ data as well as your own. Findings are triaged on the same severity targets as our own, and we will share the fix rather than dispute the finding.
Where is our data processed, and by whom?
Document bytes sit in the storage backend you configure — platform-managed storage in a region selected at provisioning, or your own S3 bucket or Azure container on Enterprise. Every third party that processes customer data on our behalf is listed on the sub-processors page with its function, location and transfer safeguard.
Is customer data used to train AI models?
No. Customer documents are never used to train, fine-tune or evaluate any model, ours or a third party’s, and that prohibition is a contractual term in the data processing addendum rather than only a statement here. AI features process your documents to return a result to you and retain nothing afterwards. Where a third-party model provider is involved it is listed on the sub-processors page and is engaged under zero-retention terms.
What happens to our documents when we leave?
Complete export with folder structure, metadata and version history intact, followed by deletion on the schedule set out in the data processing addendum. A repository you cannot fully export is a migration problem you have already bought, which is why we treat export as a security topic rather than a commercial one.
Do you support customer-managed encryption keys?
Where you configure your own S3 bucket or Azure container, key management is entirely yours — including customer-managed keys and object lock. On platform-managed storage, keys are held and rotated by us and customer-managed keys are not supported. If key custody is a hard requirement, the Enterprise tier with your own storage backend is the configuration that meets it.
How do you vet employees with production access?
Every employee with production access passes an identity, right-to-work and criminal record check before access is granted, and is bound by confidentiality terms that survive employment. Access is least-privilege, tied to a named individual rather than a shared account, and reviewed quarterly with the review recorded. No member of staff holds standing access to customer document content: reaching it requires a time-boxed break-glass grant that is approved by a second person, logged as a distinct event type in your audit trail, and alerts your administrators as it happens.
最終レビュー: 2026-09-01