Security & data protection
A factual summary of controls present in the current application — without claiming certifications or guarantees the platform has not independently established.
HTTPS enforced
The public service is configured for HTTPS and redirects HTTP traffic to HTTPS. Browser-to-site traffic is protected using TLS through the site's active certificate configuration.
Email login verification
The sign-in workflow uses time-limited email verification codes. Login and code-verification endpoints are also subject to request throttling.
Encrypted sensitive fields
Selected sensitive application values use Laravel encryption. For example, stored Companies House OAuth access and refresh tokens use encrypted model casts, and application sessions are configured for encryption.
Rate limiting
Guest authentication routes and authenticated application routes use request throttling as one layer of protection against repeated automated requests.
Verified-user filing gate
Higher-risk filing actions can be placed behind the application's verified-user middleware so merely creating an account does not automatically enable every filing action.
Administrative activity records
Privileged administrative actions and filing workflows retain operational records, including timestamps and selected request metadata, to support review and troubleshooting.
Account Security & Audit
Access controls and privileged activity records.
| TIME | ACTOR | ACTION | RESULT |
|---|---|---|---|
| 10:32 | Master user | User verification reviewed | Completed |
| 09:48 | Admin user | Plan assignment changed | Recorded |
What “encrypted” means here
It would be misleading to say that every database value is individually encrypted. The application uses encryption for selected sensitive fields and for configured session data, while other information — including data sourced from the public company register — is stored and processed in ordinary application structures. Access controls, server security, backups and operational procedures remain separate layers of protection.
Company authentication codes and personal codes
Companies House company authentication codes and identity-verification personal codes are filing credentials. The XML filing controller is designed not to persist the company authentication code as a general company record simply because it is entered for a filing. Users should not put these credentials into public notes, screenshots or support messages.
UK GDPR and public-register information
Information obtained from a public register can still be personal data when it identifies a living person. AAA WebFiling therefore does not rely on the incorrect proposition that Companies House officer or PSC information stops being personal data merely because it is publicly available.
HAMILTONN LTD is responsible for assessing its own data-protection obligations for the service, and professional users remain responsible for their own lawful processing of client and contact information. This page is a description of technical and operational controls, not a blanket certification that every use of the platform by every customer is automatically UK GDPR compliant.
Infrastructure and data location
The service is currently deployed on Hamiltonn-managed IONOS/Plesk infrastructure. This page does not make an unsupported contractual promise that every copy, backup, third-party integration or processing activity is restricted to one geographic location. Organisations that require a formal data-residency commitment should obtain that commitment separately before relying on it.
Payments
The platform includes a Stripe-based billing integration. Where Stripe checkout is enabled, card collection is handled through the payment provider rather than by storing raw card numbers in AAA WebFiling's application database. Billing references and subscription/payment state may still be stored so the platform can manage access and transaction history.
Responsible security reporting
Signed-in users can raise a support ticket for a security concern. Do not include passwords, company authentication codes, Companies House personal codes, API secrets or other live credentials in the ticket body unless a secure support process specifically requires them.
HMRC VAT connection security
Where HMRC VAT features are enabled, AAA WebFiling uses HMRC OAuth authorisation rather than asking the user to give Hamiltonn their Government Gateway password. HMRC access and refresh tokens are treated as sensitive credentials and are stored using encrypted application fields.
The VAT integration is designed with separate sandbox and production configuration, explicit production safety gates, company-to-VAT-registration binding and server-side validation before higher-risk actions. A test or sandbox connection is not treated as permission to make a production filing.
HMRC fraud-prevention controls
HMRC requires fraud-prevention information for the VAT Making Tax Digital API. The service collects the required browser, device, connection, authentication and vendor information for authorised VAT API requests. Connection information used for these controls is supplied through the trusted application edge rather than blindly accepting arbitrary client-provided values. The categories of data sent to HMRC are described in the Privacy Policy.
Submission integrity
VAT submission workflows are designed to separate preparation from final submission, require the relevant filing context and declaration, retain submission evidence and avoid blindly repeating a VAT return POST when the first outcome is uncertain. Where appropriate, the service can reconcile the outcome by retrieving authoritative HMRC data before another filing decision is made.