Security

This page describes the security controls in place around the EagleEnforce™ application and the data it holds. It is a summary written for customers and their IT teams, not a complete description of our internal controls, and it is deliberately light on detail that would help an attacker.

1. Accounts, roles and seats

Data belongs to an organization, and every request is scoped to the organization on the signed-in session. Users are invited into an organization and given a role: owner, manager, analyst or viewer. The role controls what a user can see and do, and sensitive actions are restricted: cancelling a subscription is limited to an owner, and notice approval requires sufficient permission.

Each plan sets the number of seats available. You choose who to invite and are responsible for removing users who should no longer have access.

2. Authentication

• Sign in with an email address and password, or with Google. Both can be enabled on the same account, and Google can be disconnected once a password is set.
• Passwords are stored hashed, never in readable form. We never ask for your password by email.
• New email addresses are verified before an account is fully usable.
• Password sign-in asks for a one-time code sent to the account's email address as a second factor.
• Sensitive billing changes, such as subscribing or changing plan, require a fresh emailed code even when you are already signed in.
• Staff access to our internal administration tools requires a second factor and is logged separately.

Sessions use signed, HTTP-only cookies that scripts on the page cannot read, marked secure so they travel only over HTTPS, with cross-site request forgery protection on every state-changing request. Sessions are short-lived and refreshed, so a stolen token has a limited life.

3. Encryption and data protection

• All traffic to the website and the application is served over HTTPS with modern TLS.
• Data at rest, including databases, evidence storage and backups, is stored encrypted by our hosting provider.
• Credentials for connected stores are additionally encrypted by us before they are written to the database, with keys held outside the database in the server environment, so a database copy alone does not expose them. Keys can be rotated without downtime.
• Payment-card numbers are never sent to or stored by us. Card details are entered into a form served by Square and are held by Square; our records keep only the card brand, the last four digits and payment history.

4. Safety of the monitoring system

The crawler is constrained by design as well as by policy. It identifies itself, honours robots.txt including Crawl-delay, reads one request at a time per domain, backs off when a site signals it should, and never logs in to a dealer website or attempts to defeat an access control. Sites can be excluded, and a site that blocks monitoring is not monitored. Before a dealer site is added, a preflight check confirms the site can be read within those rules. See How we collect data.

Requests to add a site are checked against internal and private network addresses to prevent the monitoring system being pointed at infrastructure it should not reach.

5. Logging and audit

Administrative and security-relevant actions are written to an audit log, including sign-ins, second-factor events, role changes, billing changes, notice approvals and staff administrative actions. Audit records are kept for up to 24 months and then pruned automatically. Application logs are kept for operational troubleshooting and are not used for advertising or profiling.

6. Backups and recovery

The database and evidence store are backed up nightly to encrypted object storage held separately from the application servers, with the restore procedure documented and the age of the most recent backup monitored so a silent failure is noticed. Backup copies are retained on a rolling schedule.

Backups exist to recover the Service. They are not a substitute for exporting data you need to keep beyond your plan's retention period.

7. Hosting and infrastructure

The Service runs on DigitalOcean infrastructure in the United States. Administrative access to production is restricted to a small number of people, requires individual credentials, and is logged. Application components run as unprivileged services with restricted filesystem access. Rate limiting is applied to authentication and other sensitive endpoints.

Our providers are listed with their purpose and location in the Privacy Policy.

8. Your part

• Use a unique password, or sign in with Google.
• Give each person their own login rather than sharing one, and use the lowest role that lets them do their job.
• Remove users promptly when they leave.
• Keep the billing email address current, since billing confirmation codes and notices go there.
• Never send passwords, full card numbers, API keys or store credentials to us by email or in a support ticket. We will never ask for them.

9. Reporting a vulnerability

If you believe you have found a security problem, email support@ecommeagle.com with "Security" in the subject and enough detail to reproduce it. Please give us a reasonable opportunity to fix the issue before disclosing it publicly, and do not access, modify or delete data belonging to anyone else while testing.

We do not currently operate a paid bug-bounty programme. Testing against the Service without our prior written permission is not permitted by the Terms of Service.

10. Incidents

If we become aware of a security incident affecting your data we will investigate, take steps to contain it, and notify affected customers as applicable law requires and within the timeframes it sets. Notifications go to the account's registered contacts.

11. Contact