Documentation Index

Fetch the complete documentation index at: https://docs.document360.com/llms.txt

Use this file to discover all available pages before exploring further.

Security and infrastructure

Prev Next

Document360 protects your data using enterprise-grade security infrastructure built on Microsoft Azure, MongoDB Atlas, and Algolia — all certified partners with industry-standard encryption and compliance controls. Every layer of the platform — data storage, network traffic, backups, and content delivery — is secured so your knowledge base and its contents remain confidential, available, and recoverable. This article explains how Document360 secures your data, what its infrastructure partners do, and how the platform ensures business continuity.


Security infrastructure at a glance

Document360's security architecture covers the following layers:

Layer Technology Key protection
Database MongoDB Atlas (multi-node cluster) TLS encryption in transit; encryption at rest; VPC isolation
Backups Microsoft Azure Blob Storage Multi-geolocation redundancy; daily, weekly, and monthly retention
Hosting Microsoft Azure Cloud DDoS protection; always-on traffic monitoring
Search Algolia SOC 2 / SOC 3 compliant; per-customer data isolation
Content delivery Azure CDN + Cloudflare Edge caching; fast global access
API access Authenticated API tokens Scoped permissions; full access control

How Document360 stores and protects your data

Database and primary data

Your knowledge base content and project settings are stored in a remote MongoDB Atlas database configured as a three-node cluster, ensuring zero downtime through high availability. All network traffic is encrypted using TLS, and data at rest is stored in encrypted storage volumes.

MongoDB Atlas dedicated clusters are deployed in a unique Virtual Private Cloud (VPC) with dedicated firewalls, preventing third-party access to your data. The platform undergoes independent verification of security, privacy, and compliance controls.

For more information, see MongoDB Atlas security documentation.

Backups

Project backups — including settings, landing pages, documentation, and all project contents — are stored in Microsoft Azure Blob Storage across multiple geographic locations. Backups are taken automatically every day at 00:00 UTC and retained as follows:

Backup frequency Retention period
Daily Up to one month
Weekly Up to one month
Monthly Up to one month

You can also trigger a manual backup at any time from within Document360. Any backup can be restored to return your project to a previous state.

Azure Blob Storage protects backup data with:

  • Encryption in transit — HTTPS secures data during transfer; client-side encryption secures data on your device before it reaches the server, where it is decrypted upon arrival.
  • Encryption at rest — Storage-side encryption is always enabled and automatically encrypts data written to Azure Storage. Client-side encryption adds a further layer of protection.
  • Advanced threat protection — Detects unusual behaviour and potentially harmful attempts to access or exploit your storage account.

For more information, see Azure Blob Storage security documentation.

Hosting and DDoS protection

Document360 is hosted on Microsoft Azure Cloud, which provides protection against Distributed Denial of Service (DDoS) attacks through always-on traffic monitoring and real-time mitigation of common network-layer attacks. Services and data are hosted in compliant data centres located in Western Europe and Central US.

Search

Algolia, Document360's search partner, isolates each customer's data in separate applications to prevent data leakage and preserve data integrity. Algolia API servers use HTTPS and TLS (1.0, 1.1, and 1.2), rated A by Qualys SSL Labs, and the platform is SOC 2 and SOC 3 compliant, following all AICPA trust service principles.

For more information, see Algolia's security documentation.


Content delivery, caching, and update visibility

Document360 uses Cloudflare edge caching for public-facing knowledge bases to improve page load speed, reduce infrastructure load, and ensure consistent global access.

Recently published or updated content may take a short time to appear for public visitors due to the cache window. When content is cached at Cloudflare's edge, all visitors see the cached version during the cache window — regardless of browser, device, or incognito mode. The following table describes cache behaviour by project type:

Project type / access Cloudflare cache Cache duration When updates appear
Public project Yes ~10 minutes Updates may be delayed for visitors
Private project No Not cached Immediate
Public version (mixed project) Yes ~10 minutes Update may be delayed
Private version (mixed project) No Not cached Immediate
Logged-in team users (any project) No Not cached Immediate

Bypass the cache to view updates immediately

If you need to verify a published update before the cache expires, append any query parameter to the article URL. Cloudflare treats URLs with different query parameters as unique requests and fetches the latest version directly, helping you view the latest update immediately after publishing.

Example:

https://support.example.com/docs/article-name?refresh=1

The query parameter value can be anything — for example, ?test=1 or ?cachebust=123.


Feedback endpoint security

The feedback form on your knowledge base site is protected against malicious input and injection attempts through the following measures:

  • Input validation and HTML context encoding prevent client-side injection attacks.
  • Prepared statements are used for all database interactions, preventing SQL injection attempts from executing queries.
  • System functions are not used to process or execute user-controlled input, eliminating the risk of command injection.
  • CAPTCHA is implemented on the feedback endpoint to block automated submissions.
  • Rate limiting is enforced to prevent abuse.

Even if a malicious payload is submitted, it cannot execute or affect the system in any way.


Penetration testing policy

Document360 does not permit customer-initiated penetration testing on its shared (public) environments. Because Document360 operates on a multi-tenant SaaS infrastructure, active penetration testing on shared environments could affect other customers. This restriction applies uniformly to all customers.

Customers must ensure that:

  • Internal teams and third-party penetration testing vendors do not perform active testing against Document360 systems.
  • Security testing is limited strictly to infrastructure and assets owned and managed by the customer.

Document360's own security testing

Document360 performs regular third-party penetration testing and security assessments as part of its ongoing security programme. The following reports are available to customers upon request to support internal audits, compliance, and security governance (including healthcare security due diligence):

  • SOC 2 reports
  • Penetration testing and other security assessment reports

Private hosting for recurring penetration testing

If your organisation requires annual or recurring penetration testing, Document360 can accommodate this in a Private Hosting (PH) environment, where testing will not affect other customers. Contact your Document360 representative to coordinate.

Compliance and risk documentation

This policy enables customers to properly document the following for internal governance and audit purposes:

  • Vendor-managed security testing coverage
  • Compensating controls
  • Risk and audit records

Customer requests for penetration testing on shared environments will receive a standard response aligned with this policy.


Business continuity and disaster recovery

Document360 is designed for high availability and rapid recovery.

  • Multiple service nodes — Multiple instances of each service run simultaneously so that if one node fails, the others continue serving requests without interruption.
  • Geo-redundant data replication — The database and data storage are replicated across different geographic locations to protect against regional failures.
  • Highly scalable DNS — Users are routed to the best endpoint based on geo-proximity, latency, and health checks.
  • Azure CDN — Application and customer documentation are served from the nearest CDN node for fast global delivery.
  • Incident and breach management — Established procedures cover reporting, tracking, investigation, and timely communication for any incident or breach.

DevOps and release process

The product roadmap is defined and reviewed periodically. Security fixes are prioritised and bundled into the earliest possible sprint. DevOps sprints involve a multidisciplinary team including the Product Owner, Director of Engineering, Developers, and Quality Assurance. Each release goes through:

  • Code review — The QA team establishes criteria for and performs code reviews, web vulnerability assessments, and advanced security tests alongside functional code reviews.
  • Quality assurance — Builds are tested for functionality, performance, stability, and UX before being certified ready for release.
  • Version control — Source code is managed centrally with access restricted by team and sprint. Records are maintained for all code changes, check-ins, and check-outs.
  • Segregation of duties — Access to production resources is restricted to a limited set of users based on job role.

GDPR compliance

Document360 is fully GDPR compliant. Only the data required to deliver its services is collected and stored, and only with explicit customer consent.

For details, see Document360's GDPR compliance page.


FAQ

Where is Document360 data stored?

Your knowledge base content and settings are stored in a MongoDB Atlas database (multi-node cluster) with TLS encryption in transit and encryption at rest. Project backups are kept in Microsoft Azure Blob Storage across multiple geographic locations. Files you upload (images, PDFs, videos) are stored in Document360 Drive, powered by Azure Blob Storage. Content is delivered to readers via Azure CDN and Cloudflare.

Can I perform penetration testing on Document360?

Customer-initiated penetration testing is not permitted on shared (multi-tenant) Document360 environments. If your organisation requires recurring penetration testing, Document360 can accommodate this in a Private Hosting (PH) environment where testing will not affect other customers. Contact your Document360 representative to arrange this. Document360's own SOC 2 and penetration testing reports are available on request.

Why does published content not appear immediately on my knowledge base?

Public knowledge bases use Cloudflare edge caching with a cache window of approximately 10 minutes. To view the latest version immediately after publishing, append a query parameter to the article URL (for example, ?refresh=1). Private projects and logged-in team users are never cached and always see updates immediately.

How long are backups retained?

Daily, weekly, and monthly backups are retained for up to 30 days. You can restore any backup at any time from within Document360. Manual backups can also be triggered on demand at any time.

NOTE

For more information about Document360's security and infrastructure, contact us or book a demo with our experts.