Security

At a glance

• TLS 1.3 in transit; AES-256 at rest with AWS KMS, keys managed in a FIPS 140-2 validated HSM.
• Uploaded documents deleted immediately after processing; results deleted five minutes after first retrieval, with a 24-hour hard limit.
• API keys shown once at creation and stored as SHA-256 hashes.
• Production access restricted to named engineers, gated by hardware-backed MFA, and recorded in audit logs.
• Object storage has no public access; origin requests to the site are SigV4-signed via CloudFront OAC.
• Webhook callbacks are signed with HMAC-SHA256 over timestamp and body to defeat replay.
• Vulnerability reports go to security@ocrwell.com — see Reporting a vulnerability.

Hosting and infrastructure

OCRWell runs entirely on Amazon Web Services in the us-west-2 (Oregon) region. We do not operate our own data centres, and there are no on-premise components in the customer data path. We rely on AWS's physical security, environmental controls, and personnel screening for the underlying facilities.

Compute runs on managed AWS services — Lambda, Fargate, and DynamoDB — so there are no long-lived virtual machines that engineers log in to. Deployments are driven by AWS CDK from a version-controlled repository; there is no manual console provisioning for production infrastructure.

Encryption

In transit

All public endpoints (ocrwell.com, the dashboard, and the customer API) require TLS 1.3. Plaintext HTTP is redirected or rejected. Certificates are issued and rotated automatically by AWS Certificate Manager. HSTS is enabled, with the apex domain served from CloudFront.

Traffic between internal AWS services travels inside the AWS backbone and is encrypted by default at the service level (S3, DynamoDB, SQS, Lambda).

At rest

Object storage (S3), job metadata (DynamoDB), and queue payloads (SQS) are encrypted at rest with AES-256 using AWS KMS customer master keys. KMS keys are held in AWS CloudHSM clusters that are FIPS 140-2 Level 3 validated. Plaintext key material never leaves the HSM.

Secrets

Service credentials (database URLs, signing secrets, third-party API keys) are stored in AWS SSM Parameter Store as SecureString values and loaded at runtime by the services that need them. They are never committed to source control and never baked into container images.

Authentication and API keys

Dashboard

Dashboard authentication is delegated to Amazon Cognito. OCRWell itself never stores or handles user passwords. Cognito manages credential storage, password-reset flows, multi-factor authentication, and throttling of repeated failed attempts, and it is covered by the SOC, ISO, PCI, and HIPAA attestations that apply to AWS as a whole.

API keys

API keys are generated from a cryptographically-random source, shown once at creation, and stored only as SHA-256 hashes. The plaintext is never retrievable after creation. On every request the server hashes the submitted key and looks it up in DynamoDB; an invalid lookup returns 401. Keys can be revoked from the dashboard and take effect immediately.

Webhook signing

Webhook callbacks are signed with HMAC-SHA256 over {timestamp}.{body}, so receivers can verify authenticity and reject stale deliveries. Verification steps are documented in the Webhook callbacks section of the API reference.

Access control

• Production access is restricted to a small number of named engineers. There are no shared accounts.
• Human access to AWS is federated through SSO with hardware-backed MFA (WebAuthn / FIDO2 security keys). Console password login to production is disabled.
• Engineers assume short-lived, role-scoped IAM sessions for any production action. No long-lived IAM users exist for people.
• Service-to-service authorisation uses IAM roles attached to each compute resource; services are granted the minimum set of actions and resources needed to do their job.
• All AWS API calls are recorded in CloudTrail and retained in a separate logging account that engineers cannot write to.
• Access is reviewed whenever a team member joins or leaves, and revoked the same day for departures.

Network and storage isolation

• S3 buckets block all public access at the account level. Uploads and reads go through short-lived pre-signed URLs (15 minutes for uploads).
• The marketing site Lambda is fronted by a Function URL with AWS_IAM authentication; CloudFront reaches it via an Origin Access Control that SigV4-signs every request. The Function URL is not callable directly from the internet.
• Inbound traffic passes through CloudFront with a managed security-headers policy (HSTS, X-Content-Type-Options, Referrer-Policy, Content-Security-Policy).
• DynamoDB tables are accessible only via IAM-authenticated API calls from our own service roles; there is no public endpoint to expose.

Application security

• Every change to production goes through pull request review, with required status checks for type-checking, tests, and dependency audits before merge.
• Dependencies are pinned by lockfile. Automated alerts flag known vulnerabilities in direct and transitive packages; security patches are prioritised over feature work.
• Code is scanned for leaked secrets before commit. Any secret that reaches a remote branch is treated as compromised and rotated.
• The customer API validates request bodies against typed schemas before any processing begins; oversized or malformed payloads are rejected at the edge.
• Document parsing runs in isolated worker processes so a single malformed file cannot affect other jobs or persist state.

Logging and monitoring

Application logs record request metadata — method, path, status code, timing, truncated user agent, source IP — along with error traces and rate-limit counters. Logs do not include document contents or extracted field values, and are retained for 30 days before automatic deletion.

AWS CloudTrail captures every API call made against our infrastructure and is stored in an append-only logging account. CloudWatch alarms page on-call engineers for elevated error rates, unusual auth-failure patterns, and sensitive IAM events.

Customer data handling

We treat customer documents as short-lived processing artefacts. Uploaded files are deleted from object storage the moment OCR and extraction finish, results are deleted five minutes after first retrieval, and a 24-hour lifecycle rule sweeps up anything that survives those steps. We never use your documents, extracted results, or derived embeddings to train or evaluate machine-learning models.

The complete set of data-handling commitments — including sub-processor list, international transfers, and your rights over account data — is set out in the privacy policy. Retention behaviour is also documented alongside the API reference.

Availability

Stateless services run across multiple availability zones within us-west-2, so a single-AZ outage does not take the service offline. State is held in managed AWS services (DynamoDB, S3, SQS) that replicate across availability zones by default.

Infrastructure is defined in code (AWS CDK). The account can be rebuilt from the repository in the event of accidental deletion or configuration loss. Professional and higher plans include a 99.9% uptime SLA; see the pricing page for details.

Reporting a vulnerability

If you believe you have found a security vulnerability in OCRWell, please email security@ocrwell.com with enough detail to reproduce the issue. We will acknowledge receipt within two business days and keep you updated as we investigate and remediate.

We ask that researchers give us a reasonable window to fix an issue before making it public, avoid accessing data that isn't their own, and do not run denial-of-service, brute-force, or spam tests against production. Acting in good faith under those terms, you will not face legal action from us.

We do not currently run a paid bug bounty, but we are happy to credit reporters publicly where they would like that.

Incident response

An on-call engineer is paged by CloudWatch alarms for elevated error rates, authentication anomalies, and sensitive IAM events. Suspected security incidents trigger a documented response: contain the affected systems, preserve logs, assess the impact on customer data, and remediate.

If an incident results in unauthorised access to personal information, we will notify affected account owners without undue delay and, where required by law, notify the relevant supervisory authority within the statutory window (72 hours under GDPR / UK GDPR; as soon as practicable under the Australian Notifiable Data Breaches scheme).

Compliance

OCRWell is a product of Corrected Cloud Pty Ltd, an Australian company. We handle personal information in line with the Australian Privacy Principles under the Privacy Act 1988 (Cth) and, where GDPR or UK GDPR applies, act as a data processor for documents submitted through the API.

Our underlying infrastructure provider (AWS) is independently audited to SOC 1, SOC 2, SOC 3, ISO 27001, ISO 27017, ISO 27018, and PCI DSS, among others. AWS audit reports are available under NDA via AWS Artifact; we can share the relevant attestations on request.

OCRWell itself does not currently hold SOC 2 or ISO 27001 certification. Enterprise customers with formal attestation requirements should contact us so we can walk through what is and is not in place today.

Contact

Security questions, vulnerability reports, and requests for vendor-assessment documentation can be sent to security@ocrwell.com. Privacy-specific requests should be addressed to privacy@ocrwell.com.

Postal address: Corrected Cloud Pty Ltd, Suite 12, Level 3, 1 Mona Vale Road, Mona Vale NSW 2103, Australia.