Our RiskGuard questionnaire answers

Apptonomy is an App Store Optimization platform delivered as SaaS. We have no access to a customer’s networks or systems: the only accounts the service touches are the App Store Connect and Google Play accounts, and optionally the Figma and Slack workspaces, that a customer chooses to connect, at the scopes they grant, and that access can be revoked at any time. With keyless Google Play linking, no Google service-account key is uploaded or stored.

We hold no independent certification or audit report yet, and have not yet commissioned an independent penetration test; the first is planned for Q1 2027. Our infrastructure providers, Google Cloud and Cloudflare, hold independent security attestations covering the platforms we run on.

The service integrates third-party commercial AI APIs — OpenAI, Anthropic, Google Gemini and Perplexity, plus Google Cloud Vision — for analysis and drafting. We do not develop or distribute AI models, and a person at the customer reviews the output before anything is published.

An Information Security Policy and sixteen annexes, approved in September 2026, each with an owner and an annual review date that an automated check enforces. Risks are rated for likelihood and impact, treated by decision of the security owner, and tracked in a register reviewed at least annually.

We run an annual control self-assessment, first performed in September 2026. It is not an independent internal audit, which a company of two founders cannot staff. Everyone with access to company systems read the first security-awareness session’s material and confirmed it in September 2026; training is required on joining and annually. Background checks are required for future hires and were not run on the two founders.

A combined business continuity and disaster recovery plan with stated objectives: a faulty release is rolled back within 1 hour; data corruption noticed within 72 hours is restored from managed backups within 8 hours with at most 24 hours of data lost. Daily encrypted exports of business-critical data are kept for 90 days under a written restore procedure, and source repositories are backed up to a separate repository. An isolated restoration of the export was exercised in September 2026; full service recovery and the rollback objective have not yet been exercised end to end, and technical recovery currently depends on one founder.

Information is classified in four tiers — Restricted, Confidential, Internal and Public — each with handling and access rules. Retention is set per data store and enforced technically where the store supports it, including 90-day expiry on application telemetry and audit logs; customer-data retention is also committed in section 9 of our Data Processing Agreement.

The service runs entirely on managed cloud resources, inventoried in version control and checked for drift automatically; endpoints, administrative accounts and domains are listed in an asset register. Laptops used for company work require full-disk encryption, built-in anti-malware, automatic updates and screen lock, and customer data is not stored on them. Copying customer data to removable media is prohibited.

Administrative access is granted per purpose. MFA is enabled on our production administrator’s accounts and required by policy on every administrative console; GitHub and Google Workspace enforce two-step verification organisation-wide. The founders’ credentials are held in a password manager and workload secrets in provider secret stores. A quarterly access review using provider records and owner attestations was first completed in September 2026, and its follow-up work is in progress. A documented procedure covers account takeover.

Our vendor policy requires vendors to be assessed before adoption and reviewed annually; those that process customer personal data are published in a versioned subprocessor list reviewed quarterly. The policy requires screening against US, EU and UK sanctions lists at adoption and at each annual review; the September 2026 screening of the vendors then in use found no designated entity.

Confidentiality rests on each vendor’s standard terms and data-processing addendum rather than separately negotiated NDAs, and we rely on the standard service-level agreements of Google Cloud and Cloudflare rather than bespoke ones.

Apptonomy is fully remote, with no offices and no servers or customer data at any company address. Production compute and data run in Google Cloud and Cloudflare datacentres, whose physical controls are covered by those providers’ independent attestations.

We process a limited set of personal data: the names, business email addresses and sign-in identifiers of a customer’s users, support messages, product-usage events (from the browser only with consent, and from our servers without that consent check, with the IP address and IP-derived location), telemetry with hashed IP addresses, and audit records with IP addresses and user agents; when stores are connected, also encrypted store credentials, listing content and store analytics. These categories and the processing terms, including the EU Standard Contractual Clauses and the UK Addendum, are in our Data Processing Agreement.

Our anti-bribery policy is written to the US FCPA, the UK Bribery Act and Dutch law, and we maintain a voluntary modern-slavery statement.

We do not measure our greenhouse-gas emissions; our footprint is two remote workers and the cloud services we consume. A code of conduct binds the founders and every future employee, contractor and agent.

A documented process with defined severities, a primary and a backup responder, and the steps of record, contain, assess, notify, recover and review. Reports reach us at security@apptonomy.ai. Our Data Processing Agreement commits us to notify an affected customer within 48 hours of becoming aware of a personal-data breach affecting their data.

No incident was classified Critical under our severity policy in the last 12 months.

Values logged through the API’s logger and the backend functions’ console logger pass through a secret redactor before they reach a log sink, and AI request and response payloads are not logged at our AI gateway. Application telemetry, audit logs and cloud platform logs are kept for 90 days; edge request logs for 7 days.

Every laptop used for company work must run built-in anti-malware with automatic definition updates, full-disk encryption, automatic updates and an automatic screen lock. We do not run device management, so compliance is confirmed at each quarterly access review.

The platform is serverless, with no private network of our own. The web and API hostnames we serve through Cloudflare sit behind its managed web application firewall and rate limiting, while our Google-hosted function endpoints are reached directly; the API applies an exact-origin CORS policy with named exceptions for the Figma plugin and incoming webhooks, an enforcing Content-Security-Policy that still permits inline scripts, and HSTS; backend endpoints authenticate each sensitive request, and one endpoint that reports the deployed build version is public. Edge rules are reviewed at least annually.

We run no dedicated intrusion-detection appliance and no outbound destination allow-list. An architecture diagram is available under NDA.

All code is in Git. Code changes land through pull requests that cannot merge until a required check passes: dependency-vulnerability audit, secret scanning, linting, type checking, tests and builds. One automation identity lands pre-verified work directly on the release branch, and a standing check reports any landing without verification of its exact tree. Staging deploys are bound to the exact verified commit, production is a separate authorised step that takes a candidate proven on staging except through a documented emergency override, releases are version-tagged, and a one-step rollback redeploys any earlier version.

Remediation deadlines are 7 days for critical, 30 for high and 90 for medium findings. Dependency audits and secret scanning block every code pull request; the external perimeter and cloud configuration are scanned at least monthly, and the staging application gets a weekly passive dynamic scan.

No independent penetration test has been run yet; the first is planned for Q1 2027 and will repeat annually. Customers are told of a critical vulnerability that put their data at risk within 72 hours of confirming it, and our public disclosure policy gives good-faith researchers safe harbour.

Patching is set by layer: our cloud providers patch the runtimes the service runs on; application dependencies are patched through the blocking audit and weekly upgrade pull requests within the severity deadlines; a CI build of the one container image we build is vulnerability-scanned when it changes and, from October 2026, monthly — that scan is not yet bound to the deployed image; laptops update automatically.

Our Encryption Policy requires TLS for all network traffic and provider-managed AES-256 encryption for every data store, adds application-level envelope encryption for customer store credentials, and sets rules for key custody, versioning and rotation: key-wrapping keys are held in Google Cloud KMS and cannot be exported, per-user data keys are derived at runtime and never stored, and service-transport and application secrets are held in managed secret stores.

We do not run a dedicated DLP product. The same risk is addressed by keeping customer data server-side and off laptops, prohibiting removable media, redacting secrets in our API and backend console logs, not logging AI payloads at our gateway, and blocking credentials in code through secret scanning.

Sign-in is provided by Clerk: emailed code or link, Google sign-in, and passkeys, including FIDO2 hardware keys; a password is set at sign-up and used to re-verify sensitive actions, not to sign in. Users can add authenticator-app MFA with backup codes. Passwords must be at least 15 characters and are checked against known-breach corpora when set and when used to re-verify, and accounts lock after repeated failed attempts.

Four organisation roles — owner, admin, member and viewer — are resolved on the server for each request, and we are completing their enforcement across every operation. Staff changes to a customer organisation and staff reads of its audits through our application require an internally approved, justified and expiring support-access grant; each use is recorded in the organisation’s activity log, and grants and revocations are recorded there on a best-effort basis. Staff reads of account and organisation records in our internal admin console need only a privileged staff session, with no per-organisation grant, and are not shown in that log. Direct operator access through our infrastructure and identity-provider consoles, including the identity provider’s own user-impersonation capability, is also outside that log. Our application has no impersonation feature of its own. SAML single sign-on and SCIM provisioning are not yet available.

Our Change Management and Secure Development Policy, reviewed annually, takes every change from a ticket through an isolated branch and automated gates — including static application security testing that blocks new error-severity findings — to staging and then production. The application uses no SQL database, binds analytics query values as parameters, escapes output by default, enforces a Content-Security-Policy, and authenticates API calls with bearer tokens rather than cookies.

Production and staging have separate customer databases, analytics datasets, service identities and keys, and the staging credential was denied on the tested production surfaces; a read-only public-store cache is shared. Routine automated tests use synthetic data, and controlled recovery exercises use encrypted production backups. Isolation of every local, preview and sandbox path is still being verified, so we cannot yet give an unqualified assurance that customer data is excluded from all non-production environments.

With no servers or networks of our own in the customer-data serving path, hardening is platform configuration: per-environment key-value and object storage isolation enforced by a deploy-blocking check, secrets only in managed secret stores, key-wrapping keys that cannot be exported from Cloud KMS, per-purpose automation identities (a stored key for the backend runtime identity is still used by many CI jobs), and centrally applied security headers. Our automated operations sessions on our build infrastructure read excerpts of production telemetry. Exposed hostnames and services are reviewed annually and scanned monthly against a reviewed inventory.

All stored data is encrypted with AES-256 by our storage providers. App Store Connect and Google Play credentials are encrypted in the browser before upload and then receive application-level AES-256-GCM envelope encryption under keys protected by Google Cloud KMS. Traffic uses TLS 1.2 or higher, with TLS 1.3 enabled and HSTS on the hostnames we serve through Cloudflare.

Customer personal data is processed by the subprocessors in our published list, which gives each one’s purpose, data categories, location and contractual basis. We give at least 30 days’ notice before adding or replacing one, except where an urgent security, legal or service-continuity need makes advance notice impracticable, in which case we give notice as soon as reasonably possible; where the EU Standard Contractual Clauses govern the transfer, their advance-notice period applies and prevails over that exception. Customers may object on reasonable data-protection grounds, and anyone can subscribe to change notices.

Organisation owners and admins can view and filter an activity log of membership and role changes, invitations, store-credential changes, publishes, and each use of Apptonomy support access, with support-access grants and revocations recorded on a best-effort basis. Entries record timestamps, actors, actions and resources, with names and request-origin details where available; some record authorization or dispatch rather than a completed outcome. Entries are kept for 90 days. The log exports as CSV or JSON; streaming to a SIEM is not offered.

Sessions are short-lived signed tokens verified on our servers for every request. Our public forms have bot verification, per-IP rate limits apply at the edge, and sessions can be revoked individually. Per-customer IP allow-listing is not offered.

Our internal admin console’s web interface sits behind Cloudflare Access with a one-time PIN, its API requires a signed session plus a server-side administrator check that fails closed, and instrumented administrative actions are audit-logged.