Privacy Policy

We collect and process the following categories of personal data:

• Account data: full name, work email address, job title, and organizational role. Collected when an account is provisioned or when a user accepts an invitation.
• Contact data (non-login participants): name, email address, mobile number, organization name, and title for Contacts (external vendors, building managers, auditors, and other BCP participants who do not hold a Beacon login).
• Mobile numbers: stored for the purpose of delivering emergency SMS and WhatsApp notifications. Mobile numbers are never sold, rented, or shared beyond the delivery channels described in Section 3. Audit logs and application log lines record only the last four digits of a mobile number, never the full number.
• BCP operational data:questionnaire responses, location records (name, address, latitude, longitude, state/area code), team rosters, drill plans and results, incident records, corrective actions, and readiness certificates. This data is entered by customer administrators and reflects the customer’s own business continuity information.
• Audit log data: a timestamped, append-only record of every significant action taken in the platform (who, what, when, from which IP address). Actor identity is recorded for both Beacon users (by user ID) and Contacts (by contact ID).
• Chat log data: questions submitted to the in-app Help assistant and the AI-generated responses. Each exchange is stored with token counts and an estimated cost figure for billing and cost-control purposes. No personally identifiable information should be included in chatbot questions (see Section 7).
• IP addresses: recorded in audit log rows and in chat log rows, and used transiently for rate limiting. Not linked to browsing activity or sold.
• File uploads: documents attached to questionnaire fields (logos, plan PDFs, drill reports). Stored in the application database, scoped to the customer tenant, and served only to authenticated users within that tenant.
• SSO configuration secrets: Microsoft Azure AD client secrets entered by platform administrators for per-tenant SSO configuration. Stored AES-256-GCM encrypted at rest; never returned in plaintext through any API endpoint.

Personal data is used solely to provide and operate the Service:

• Authenticating users and enforcing role-based access control.
• Delivering emergency notifications (SMS, WhatsApp, email) to users and Contacts when drills are scheduled or started, incidents are declared, or real-time hazard alerts match a registered location.
• Supporting drill execution, incident coordination, and BCP planning workflows.
• Maintaining the append-only audit trail for security review and compliance.
• Operating the in-app Help assistant (questions forwarded to Google Gemini for processing; see Section 7).
• Billing analysis and platform cost management (chat log token counts).

Beacon does not sell personal data, does not use it for advertising, and does not share it with third parties except as described in Section 3 (sub-processors required to deliver the Service).

Beacon is a multi-tenant platform. Every record is scoped to a single customer tenant, and the application enforces tenant scoping on every database query. One customer’s users, data, and notifications are never accessible to another customer. Platform administrators (Beacon staff) can access any tenant for support purposes, and every such access is recorded in the audit log under the “PLATFORM” audit category.

Beacon relies on the following third-party services to deliver the platform. Each sub-processor receives only the minimum data necessary for their function.

Beacon uses the following cookies:

• Session cookie: httpOnly, Secure, SameSite=Lax. Contains the encrypted JWT session (issued by Auth.js / NextAuth). Required for authentication; without it the platform cannot function.
• MFA staging cookie: short-lived (15-minute TTL), httpOnly, Secure. Used only during the TOTP multi-factor authentication flow for platform administrators.
• Active-tenant cookie (beacon_active_tenant): used only by Beacon platform administrators (PLATFORM_ADMIN role) to track which customer tenant they are currently impersonating. Validated server-side on every request; tampered values fall back to the first available tenant.
• Readiness document OTP cookie: 1-hour TTL, httpOnly, Secure. Set after a recipient successfully verifies a one-time passcode to access an email-gated readiness document. Scoped to the specific share token.
• Consent preference (beacon_consent_v1): a first-party value stored in your browser that records your cookie choice. Set only after you interact with the consent banner; contains no personal data.

The cookies above (other than the consent preference) are strictly necessary and are always on. Beacon uses no advertising cookies and no cross-site tracking cookies.

Retention periods by data type:

• Audit log rows: retained indefinitely and cannot be deleted. The append-only, immutable audit log is a core compliance and security feature. This is enforced at the application layer.
• Operational data (drills, incidents, questionnaire responses, plans, certificates): retained for the life of the customer subscription. On subscription termination, the customer may request an export before data is removed.
• User accounts: when a user is removed, their account is deactivated (is_active = false). Where the user has no blocking references in the audit log or other operational records, the row is hard-deleted. Where blocking references exist, the record is anonymized in place: name replaced with “[Deleted user]”, email replaced with a non-routable address, and all credentials and tokens nulled. This preserves audit history without retaining identifiable data.
• Contact records: Contacts (non-login participants) can be hard-deleted when they are removed by an administrator, subject to any blocking foreign-key references.
• Notification records: retained for delivery tracking and comms-status rollup. Not automatically purged.
• Chat log records: retained for billing analysis and cost management. Not automatically purged.
• Emergency alert records (EmergencyAlert, AlertDispatch): retained for historical reference and deduplication. Not automatically purged.
• File uploads: retained until the associated record (questionnaire response, drill report, etc.) is deleted. Subject to the same retention rules as operational data.

The in-app Help assistant uses Google Gemini to answer questions about the Beacon platform. Questions are processed in real time by the Gemini API and are also stored in Beacon’s own database (question text, AI response, token counts, estimated cost, and IP address) for platform cost tracking and quality review.

Important:do not submit personal data, confidential business information, passwords, or security credentials in chatbot questions. The chatbot is designed to answer questions about Beacon’s features and workflows only. Sensitive queries (those matching known patterns for passwords, credit card numbers, or similar information) are filtered before reaching Google and are refused.

Beacon applies the following technical and organizational security measures:

• Encryption in transit: all connections to the platform are HTTPS-only. SMTP connections use TLS.
• Encryption at rest (sensitive secrets): SSO client secrets and other sensitive configuration values are encrypted using AES-256-GCM with a scrypt-derived key before being stored in the database. The master key is held exclusively in environment variables and never written to the database.
• Password hashing: passwords are applicable only to PLATFORM_ADMIN accounts (all other roles are SSO-only). Platform administrator passwords are hashed with bcrypt before storage.
• Role-based access control (RBAC): every API endpoint enforces a role check before processing any request. The frontend may hide UI elements for lower-privileged roles, but the backend is the authoritative enforcement point.
• Audit log immutability: audit records cannot be modified or deleted through any application interface. They are enforced append-only at the application layer.
• Antivirus scanning: file uploads are scanned via ClamAV before being stored. In production environments with ClamAV configured, uploads are rejected if the scanner is unavailable.
• Rate limiting: login attempts (10 per 15 minutes per IP), API endpoints, and chatbot queries are rate-limited to reduce abuse.
• Mobile number privacy in logs: full mobile numbers are stored where operationally necessary (for SMS/WhatsApp dispatch), but only the last four digits are ever recorded in audit log entries or structured log output.

No security system provides absolute protection. In the event of a personal data breach, Beacon will notify affected customers as required by applicable law.

Depending on your jurisdiction, you or your organization may have the following rights with respect to personal data Beacon holds:

• Right of access: to obtain a copy of the personal data held about you. Audit log data can be exported in CSV format by authorized administrators.
• Right of rectification: to correct inaccurate personal data. Name and email corrections can be made by a COMPANY_ADMIN within the platform.
• Right to erasure: users can be deactivated and, where no blocking audit references exist, hard-deleted. Where references exist, the account is anonymized in place so that audit history remains intact. Contacts can be fully deleted subject to the same reference check.
• Right to data portability: the audit log can be exported as a filtered CSV by users with the export_data permission.
• Right to restriction and objection: users can opt out of email and SMS notifications within their profile settings (subject to an administrator approval step for email and SMS, given their role in emergency alerting). WhatsApp opt-out is fully self-service.

Because Beacon is a data processor acting on behalf of the customer organization (the data controller), data subject rights requests should be directed in the first instance to the customer organization that holds the subscription. The customer’s COMPANY_ADMIN can act on most requests directly within the platform. Requests that require Beacon’s involvement as platform operator should be submitted to info@outamation.com.

Beacon operates as a data processor on behalf of the customer organization, which is the data controller in respect of personal data entered into the Service. Beacon processes personal data only on the documented instructions of the controller (as set out in the applicable subscription agreement or Data Processing Agreement). A Data Processing Agreement (DPA) is available upon request at info@outamation.com.

We may update this Privacy Policy from time to time. Material changes will be communicated to customer administrators before taking effect, with the effective date updated at the top of this page.

Privacy questions and data subject requests should be directed to: info@outamation.com.