Information Security

Last updated: July 2026

This article describes how Doclio protects the project data you upload — drawings, annotations, defect logs, reports, and the metadata around them. It is intended for IT and procurement teams evaluating Doclio for use on construction projects, and as a reference for our existing customers' security reviews. Doclio is used by construction teams internationally and is built and operated by an Australian company; this document explains how we protect your data wherever your projects are.

Companion documents:

• Privacy Policy — legal disclosure, sub-processors, GDPR/APP rights, retention periods
• Terms of Service — account, billing, content ownership, liability

Definitions: "Doclio" or "we" means Littlebird Australia Pty Ltd ABN 83 111 099 775 trading as Doclio. "Your data" means project content you upload or create in the Service, plus account metadata. "Sub-processor" means a third-party service provider we use to deliver the Service.

1. Hosting & Infrastructure

Doclio is a fully cloud-hosted SaaS application. We do not operate our own data centres. The platform runs on three managed infrastructure providers:

Layer	Provider	Purpose
Application database, authentication, server-side functions	Supabase	Postgres database, user auth, edge functions for billing/email/AI orchestration
File storage	Cloudflare R2	Uploaded drawings (PDF), documents, annotation attachments
Static frontend & request-path compute	Cloudflare Workers / Pages	Serves the React app bundle; routes API requests; does not persist customer data

Cloudflare Workers are stateless request-path compute — persistent customer data lives only in Supabase Postgres and Cloudflare R2.

2. Data Residency

2.1 Where your data is stored today

• Database, authentication, edge functions: Supabase project hosted in ap-southeast-1 (Singapore). This is the primary location for account data, project metadata, annotations, comments, billing records, and AI query logs.
• Uploaded files (drawings, documents, attachments): Cloudflare R2 object storage. R2 supports jurisdictional location hints (Western/Eastern North America, Western/Eastern Europe, Asia-Pacific, Oceania); we can pin storage to a specific jurisdiction on request for customers with that requirement.
• Frontend / request-path: Cloudflare's global edge network. No customer data is persisted at this layer; requests are routed to the providers above.
• Backups: handled by Supabase within the same region as the primary database.

2.2 Regional data-residency options

Doclio's standard deployment stores data in Singapore (Supabase ap-southeast-1), with uploaded files in Cloudflare R2. For enterprise engagements with a data-residency requirement, we can provision a dedicated deployment in your required region — for example the European Union, the United States, other Asia-Pacific locations, or Australia (Supabase ap-southeast-2, Sydney; a jurisdiction-restricted R2 bucket) — as a separate, contracted engagement. This is not the default and is scoped before procurement, so please contact us early if you have this requirement.

2.3 CLOUD Act caveat

Both Supabase Inc. and Cloudflare Inc. are US-incorporated companies. Under the US Clarifying Lawful Overseas Use of Data (CLOUD) Act, US authorities can in principle compel a US-incorporated provider to produce data regardless of where that data is physically stored. Region pinning therefore reduces — but does not eliminate — exposure to US legal process. Customers with strict data-sovereignty requirements (typically government, defence, or regulated infrastructure) should self-select before deep procurement engagement; Doclio does not currently support sovereign-cloud platforms (AWS GovCloud, Azure Australia Government, etc.).

3. Encryption

3.1 In transit

All connections to Doclio use HTTPS with TLS 1.2 or higher and modern cipher suites. This applies to:

• The web app at doclio.app and the support site at support.docl.io
• API requests from the app to Supabase and to our edge functions
• File uploads and downloads to/from Cloudflare R2 via signed URLs
• Webhook traffic between Stripe, Supabase, and our edge functions

HTTP connections are redirected to HTTPS at the edge.

3.2 At rest

• Database (Supabase Postgres): encrypted at rest with AES-256. This covers table data, indexes, write-ahead logs, and automated backups. Encryption keys are managed by Supabase.
• Object storage (Cloudflare R2): all objects are encrypted at rest with AES-256-GCM by default. Encryption is automatic and applies to every uploaded drawing, document, and attachment.

References: Supabase Security, Cloudflare R2 Data Security.

4. Authentication

User authentication is handled by Supabase Auth. Doclio does not store passwords, password hashes, or session tokens in its application schema; password hashing (bcrypt) and session management are performed by Supabase.

Supported sign-in methods:

• Email + password — the default method. Minimum 6 characters; hashes stored by Supabase.
• Magic-link OTP — available as an alternative. A short-lived single-use link is emailed to the user; clicking it establishes a session. No password to phish, reuse, or leak.
• Google OAuth (Sign in with Google).
• Microsoft OAuth (Sign in with Microsoft / Azure AD work or school accounts).

Magic-link emails are sent from noreply@send.docl.io via our custom SMTP setup — not from a Supabase-default domain — which keeps deliverability and DMARC alignment under our control.

5. Authorisation & Access Controls

5.1 Project scoping

Every project's content (drawings, annotations, comments, attachments, reports, revision data) is scoped to its owning project and accessible only to:

• The project owner
• Users explicitly invited via a project, discipline, drawing, or workspace share
• Users in the same organisation as the project owner where an org-context share has been created

Being in the same organisation as another user does not, by itself, grant access to that user's projects. Organisations are billing entities, not security boundaries. Access is granted only when a project owner explicitly creates a share.

5.2 Capability tiers

Each share carries one of four capability tiers, enforced both client-side (UI) and server-side (database):

• View — read-only access to drawings and annotations
• Comment — view + add comments to annotations
• Contribute — view + comment + create or edit annotations and drawings
• Edit — full project access including reports, settings, and member management

5.3 Server-side enforcement (Row-Level Security)

Postgres Row-Level Security (RLS) policies enforce capability tiers at the database layer. Even if a user's UI is bypassed (e.g. a direct API call), the database itself rejects unauthorised reads and writes. RLS is enabled on every project-scoped table, including:

• drawings, drawing_revisions, revision_comparisons
• actions, action_comments, action_attachments
• reports, report_items, report_drawings, report_attachments, report_activity_log

RLS policies use SECURITY DEFINER capability helper functions (auth_can_view_project, auth_can_comment_on_project, auth_can_contribute_to_project, auth_can_edit_project) that resolve a user's effective capability across project ownership, direct shares, and org-context shares. Server-side capability enforcement was hardened in April 2026 to close the gap where capability checks had been client-side only.

5.4 Public-link safeguards

Two flows produce public, unauthenticated access via tokenised URLs:

• Approval requests — an emailed approver receives a link with a single-use approval token. The token grants read-only access to one annotation and one approval action; nothing else on the project is visible. Tokens are scoped per-annotation and revoked when the annotation is deleted.
• Public report links — report owners can mark a report as "anyone with the link". Anonymous viewers can read only the report's contents (selected annotations and drawings); they cannot see the broader project, other reports, settings, or members.

Both public-access paths run through dedicated RLS policies that grant access only when an unauthenticated request matches a valid token; logged-in users on unrelated accounts do not see public report or approval data.

6. Sub-Processors

Doclio uses a small set of trusted third-party service providers ("sub-processors") to deliver the Service. The current list, with each provider's role and processing scope, is maintained in our Privacy Policy § 5.1. We update that list when sub-processors change and, where required, provide reasonable advance notice.

Summary of the data each receives:

• Supabase — database, authentication, server-side functions (account data, project data, AI query logs)
• Cloudflare R2 — object storage (uploaded files only)
• Stripe — payment processing (billing details only; we never see full card numbers)
• Anthropic — AI model inference (prompts and selected project context for AI queries; per Anthropic API terms, your data is not used to train models)
• Tavily — optional AI web-search fallback (only when explicitly invoked)
• Resend — transactional email (share invites, notifications, approvals)
• Migadu — inbound mailbox provider for our @docl.io business email
• Sentry — error tracking and performance monitoring (text content masked)
• Google — analytics (GA4) and tag management (consent-gated; IPs truncated)
• Microsoft — Clarity session replay (Strict masking; consent-gated; form input + annotation content masked at capture)

Voice dictation is deliberately absent from this list. The AI Assistant's optional microphone uses speech recognition built into the browser: the browser captures the audio and sends it to its own vendor under the user's relationship with that vendor. The audio never reaches our infrastructure, so we are not the controller of that transfer and the browser's maker is not our sub-processor. It is disclosed in section 12 of our Privacy Policy rather than here. A user who does not want audio leaving their device simply types instead.

7. Data Export & Deletion

Doclio provides self-service data export and account deletion for every user, aligning with GDPR Article 15 (right of access), Article 17 (right to erasure), and Article 20 (right to data portability), and with the equivalent rights under the Australian Privacy Principles and comparable data-protection laws in other jurisdictions.

• Data export — available from Settings → Privacy & Data. Generates a structured archive (account profile, projects, drawings, annotations, comments, reports, activity log) and emails a time-limited download link. Implemented as a token-authenticated edge function with the export staged on Cloudflare R2.
• Account deletion — also available from Settings → Privacy & Data. Triggers an irreversible cascade that removes user-owned projects, drawings, annotations, comments, attachments, reports, shares, and the auth record itself. Backups are retained for up to 90 days before purging (see Privacy Policy § 7).

For Australian users, requests under the Australian Privacy Principles can also be raised at privacy@docl.io; for EU/UK users, the same address handles GDPR/UK GDPR rights requests.

8. Audit & Monitoring

• Application errors and performance — captured via Sentry with text content masking. Used to diagnose bugs and regressions; not used for marketing or profiling.
• Subscription & billing events — recorded in a dedicated subscription_events audit table covering Stripe webhook deliveries (checkout, subscription create/update/delete, invoice.paid, payment_failed).
• Report viewing — reads to public report links are logged to report_activity_log for the report owner.
• AI usage — query metadata (model, token counts, credit cost, timestamp) is logged to ai_query_log for billing and abuse detection. Query content is retained only as long as needed for those purposes (see Privacy Policy § 7).
• RLS policy testing — capability-matrix tests verify the database RLS policies behave correctly for each capability tier, including write-attempt rejections from view-only and comment-only users.

9. Vulnerability Handling & Responsible Disclosure

If you believe you have found a security vulnerability in Doclio, please report it to legal@docl.io. We commit to:

• Acknowledging your report within 5 business days
• Keeping you informed of remediation progress
• Not pursuing legal action against good-faith researchers who follow this policy

Please do not:

• Access, modify, or destroy other customers' data
• Run automated scans against production that degrade availability for other users
• Publicly disclose the vulnerability before we have had a reasonable opportunity to fix it

Dependencies are updated regularly and high-severity advisories on critical libraries are patched promptly.

10. What We Don't Have (Transparency)

To set realistic expectations for procurement reviews, here is what Doclio does not currently hold or operate:

• No SOC 2 attestation in our own name. (Our database/auth provider Supabase holds SOC 2 Type II covering its platform — this benefits the underlying infrastructure but is not an attestation of Doclio's application-layer controls.)
• No ISO 27001 certification in our own name. (Same caveat: Supabase holds ISO 27001 for its platform.)
• No HIPAA Business Associate Agreement available from Doclio. Do not upload Protected Health Information (PHI) to the Service.
• No third-party penetration test report. We perform internal review and dependency monitoring, but have not commissioned an external pen test.
• No IRAP / FedRAMP / CMMC / sovereign-cloud assessment.
• No SSO / SAML / SCIM for end-user provisioning today (the Enterprise plan lists this as a roadmap item; contact us if it is a procurement blocker).
• No customer-managed encryption keys (BYOK). Encryption keys are managed by Supabase and Cloudflare R2.

If a control on this list becomes a hard requirement for your project, please contact us — we are happy to discuss timelines and scoping options. We would rather be transparent about gaps than overclaim.

11. Provider Compliance (Reference)

While the certifications above are not held by Doclio in its own name, the underlying infrastructure providers do publish their compliance posture:

• Supabase — SOC 2 Type II, HIPAA, ISO 27001. See supabase.com/security.
• Cloudflare — SOC 2 Type II, ISO 27001, ISO 27018, PCI DSS. See cloudflare.com/trust-hub.
• Stripe — PCI DSS Level 1. See stripe.com/docs/security.

These attestations cover the providers' platforms, not Doclio's application logic, and should not be cited as Doclio certifications.

12. Data Breach Response

In the event of a security incident affecting customer data, we will:

• Notify affected customers and the Office of the Australian Information Commissioner (OAIC) within the timeframe required by the Notifiable Data Breaches scheme under the Australian Privacy Act 1988
• Notify EU/UK supervisory authorities within 72 hours where GDPR Article 33 applies
• Provide a written summary of the incident, the data affected, the remediation actions taken, and recommended steps for affected users

13. Contact

• Security disclosures: legal@docl.io
• Privacy / data-protection requests: privacy@docl.io
• General support: hello@docl.io or support.docl.io
• Registered office: Littlebird Australia Pty Ltd (trading as Doclio), Level 3, 1060 Hay Street, West Perth, WA 6005, Australia
• ABN: 83 111 099 775

Disclaimer: This document describes Doclio's information-security posture in good faith and is intended to support customer security reviews. It is not a contract, warranty, or certification. Specific contractual representations are governed by your subscription agreement and our Terms of Service. Where this document and the Terms of Service conflict, the Terms of Service prevail.