Legal
Security
- Effective
- Last updated
This page describes how we protect the platform, what we ask of you, how we handle incidents, and how to report a vulnerability with our explicit permission to look.
It is written to be checkable. Where we have not done something — an external audit, for instance — it says so rather than implying otherwise.
1.Security by architecture
The strongest security property of SmartOrderCapture is structural rather than procedural: workflows execute on your device, and the screen content the Android Accessibility Service reads is processed there and never transmitted to us. There is no central store of what your phone has been looking at, because we never receive it.
What we do hold is described precisely in the Privacy Policy: account details, workflow definitions, device records, run metadata and traces, and billing status.
2.How the platform is protected
Accounts and access
- Passwords are stored only as salted, computationally expensive hashes — never in plaintext or reversible form.
- Optional TOTP two-factor authentication, with enrolment confirmed before it takes effect.
- Sessions are bound to expiring tokens, recorded with IP address and user agent, and revocable from Settings.
- Cloudflare Turnstile guards sign-in, sign-up and password reset against credential stuffing and automated abuse.
- Rate limits apply per account and per client address across authentication and API endpoints.
Data
- TLS for all traffic between your browser, your device and our servers.
- Encryption at rest at the storage layer for the database, object storage and backups.
- Encrypted, regularly exercised backups with a bounded retention window, so deleted data ages out.
- Run retention is configurable per account, defaulting to 30 days, so the most sensitive record we hold is also the shortest-lived.
Operations
- Least-privilege access for staff; administrative actions are recorded in an append-only audit log with actor, action, IP and user agent.
- Support impersonation, where used, requires a stated reason, is time-limited, and is logged as its own record.
- Secrets are held in the deployment environment, never in the repository.
- Dependencies are pinned and updated; error monitoring runs with personally identifying request data disabled and sensitive headers scrubbed.
Abuse containment
- A compiled denylist blocks workflows from targeting prohibited application packages, enforced on the device so it holds offline, and mirrored server-side to reject offending workflows before they sync or publish.
- A per-workflow kill switch stops a specific workflow executing on every device it is synced to.
- Marketplace templates pass automated checks before publication, and can be unpublished immediately.
3.What you control
Security here is shared. The highest-leverage things on your side:
- Turn on two-factor authentication, and use a unique password.
- Keep run retention short, and avoid putting passwords, card numbers or one-time codes into workflow steps — those values can appear in an execution trace.
- Review what a template does before installing it. Templates come from other users, and a verified safe marker is an automated check, not a warranty.
- Keep your phone locked, encrypted and updated. Accessibility permission is powerful.
- Unpair devices you no longer use, and revoke sessions you do not recognise.
- Install the Android application from Google Play or directly from us, and never from a third-party mirror.
4.Incident response
If we detect or are told about a security incident, we investigate immediately, contain it, and work out what data was affected. Where a breach affects personal information, we notify affected users and the relevant authorities as the law requires, and without undue delay — we aim to give affected users an initial notice within 72 hours of confirming impact, even where the full picture is still incomplete.
Notices will say what happened, what data was involved, what we have done, and what you should do. We would rather send an early, partial notice than a late, tidy one.
5.Reporting a vulnerability
If you have found a security issue, we want to hear about it. Email security@smartordercapture.com with enough detail to reproduce it: the endpoint or screen, the steps, what you expected and what happened, and any proof-of-concept. Please give us a reasonable period — 90 days is our default — to fix it before publishing.
We acknowledge reports within two business days and keep you updated until it is closed.
Safe harbour
In scope
- The smartordercapture.com website and its API.
- The SmartOrderCapture Android application.
- Authentication, authorisation, tenant isolation, and the denylist and kill-switch enforcement paths.
Out of scope
- Denial-of-service and volumetric testing, and anything degrading service for other users.
- Social engineering of our staff, users or vendors, and physical attacks.
- Accessing, modifying or exfiltrating data that is not your own. Stop at proof of access and tell us.
- Reports produced only by an automated scanner, with no demonstrated impact.
- Missing best-practice headers, weak TLS ciphers or version disclosure without a working exploit.
- Vulnerabilities in third-party services — report those to the vendor.
- The fact that the Android application can, with permission you grant, control your device. That is the product.
We do not run a paid bounty programme at this stage. We do credit researchers publicly with their consent, and we answer every report from a person.
6.Security contact
security@smartordercapture.com reaches the people who can act. For anything time-critical, put “URGENT” in the subject. For account issues that are not security-related, use support@smartordercapture.com instead.