Security at DAWN

1. Security approach

DAWN applies risk-based technical and organisational measures to protect the confidentiality, integrity, availability and resilience of personal and organisation data. Controls are selected according to the sensitivity of the data, the capability being used, the people who may be affected and the operational environment.

Security is reviewed across the service lifecycle, including account design, code changes, provider configuration, deployment, monitoring, support and incident response. No single control is relied upon to protect high-impact workforce information.

2. Identity and access management

• DAWN requires authenticated accounts for protected workforce features.
• Passwords are stored as one-way bcrypt hashes and are not available to administrators in plain text.
• Access tokens expire and protected backend endpoints validate the authenticated user.
• Role-based permissions separate candidate, employer, administrator and team-member capabilities.
• Invitation and account-verification workflows are used before access is activated where the feature requires them.

Organisation administrators must grant the least access needed, review membership regularly and remove or change access promptly when a person changes role or leaves. A role shown in the interface is not a substitute for backend authorisation.

3. Data and credential protection

Production traffic must use encrypted network connections. Provider API keys, telephony credentials, identity-provider secrets and signing keys are backend configuration and must not be placed in browser code, public environment variables, source control, support messages or test fixtures.

DAWN's AI usage records are designed to retain operational metadata and a content hash instead of raw prompts and responses. DAWN's telephony audit records are designed to retain hashed destination and message values. This minimisation reduces exposure, but it does not make associated operational data anonymous in every context.

Production secrets must be stored in an access-controlled secret system, rotated after suspected exposure and limited to the service and environment that require them. Local development must use dedicated test credentials and synthetic data.

4. Application and infrastructure security

DAWN separates browser, application, AI gateway, telephony gateway, database and object-storage responsibilities. The browser calls DAWN backend endpoints and does not receive permanent AI or carrier credentials. Backend services validate request identity, capability and input before calling a configured provider.

Code changes must be reviewed and tested in proportion to their risk. Dependencies, configuration and deployment settings must be kept current. Production environments must use restricted network origins, non-default signing secrets, controlled database permissions and protected storage. Test and production data must remain separated.

5. AI, speech and telephony providers

DAWN uses backend gateways to route approved reasoning, speech-to-text, text-to-speech and telephone capabilities. Each provider receives only the information needed for the selected task and capability, subject to the configured route and organisation instructions.

Provider availability, data location, retention and security terms must be assessed before production use. A fallback provider must meet the same minimum contractual, privacy and security requirements as the primary provider. DAWN must not retry an ambiguously accepted telephone call through another carrier where that could cause a duplicate call.

6. Logging, monitoring and audit information

Operational events are recorded to diagnose failures, detect misuse, investigate incidents, measure provider reliability and evidence review of high-impact AI output. Logs must not intentionally contain passwords, API keys, verification codes, full audio, raw prompts or unnecessary workforce data.

Access to logs and audit records must be limited to authorised people with an operational need. Retention must follow the purpose of the record and the relevant controller's schedule.

7. Availability, backups and recovery

DAWN is designed to isolate provider failures and, where safe, route an eligible request to an approved fallback. Circuit breaking, timeouts and idempotency controls reduce repeated failures and duplicate actions. These measures do not guarantee uninterrupted service.

Production data requiring recovery must be covered by controlled backup and restoration procedures. Backups must be access-controlled, tested, rotated and removed under the applicable retention schedule. Organisations remain responsible for exports or independent records that law or their own continuity plan requires them to retain.

8. Security and personal-data incidents

A suspected incident is triaged to determine scope, affected systems, data, users and organisations. The response process includes containment, preservation of relevant evidence, remediation, recovery, assessment of legal duties and measures to reduce recurrence.

When DAWN acts as processor, we notify the controller organisation without undue delay after becoming aware of a personal-data breach affecting its data and provide information reasonably needed for its assessment. When DAWN acts as controller, we make required notifications to the competent authority and affected people within the periods set by applicable law.

If an account or device may be compromised, stop the affected action, change exposed credentials through a trusted device and contact security@dawnhcm.com.

9. Organisation and user responsibilities

Organisations and users must:

• use unique credentials, protect devices and never share accounts or verification codes;
• configure roles, providers, retention and integrations for the sensitivity of their workforce data;
• upload only information they are authorised and legally permitted to process;
• verify important AI output and require meaningful human review before a consequential action;
• remove access promptly, keep recovery information current and report unexpected access or behaviour; and
• avoid using production data in local development, demonstrations or support reports.

10. Reporting a vulnerability

Send a concise report to security@dawnhcm.com. Include the affected URL or feature, the observed result, reproducible steps, the date and time, and a safe way to contact you. Remove personal data and secrets from screenshots or files.

Do not access another person's data, disrupt service, use social engineering, persist after confirming the issue, demand payment, or disclose the vulnerability publicly before there has been reasonable time to investigate and remediate it. We ask researchers to act in good faith and will assess responsible reports without treating accidental, limited interaction as malicious.

11. Assurance, changes and limitations

This public overview is not a penetration-test report, audit opinion or certification. DAWN does not claim ISO, SOC or another independent certification unless it is expressly identified with its scope and current validity. More detailed assurance information may be shared with an authorised organisation under appropriate confidentiality.

No internet service is completely secure. We update this page when material security responsibilities or safeguards change.