Australian data residency
Personal information, engagement artefacts, lab inputs and outputs, generated PDFs, lead enquiries, and operational logs are stored on Australian-region infrastructure by default. Where we use managed services, we configure them to keep data inside Australia where the provider supports it — primarily AWS Sydney (ap-southeast-2) or Microsoft Azure Australia East.
Where a client requires non-Australian residency for a specific reason, that election is documented in the engagement agreement and the DPA at /dpa. We do not quietly route client data across borders.
Encryption
- In transit: TLS 1.2 or higher across every public endpoint, with HSTS preload pinning HTTPS for two years
- At rest: AES-256 on managed datastores, including the lead pipeline KV store, generated PDFs, and engagement records
- Backups: encrypted backups with separation of encryption keys from the data they protect
- Secrets: environment-scoped via the platform's encrypted secret store; never committed to version control; rotated on personnel changes
Identity and access management
- Role-based access with least-privilege defaults; standing access is the exception, not the rule
- Multi-factor authentication required for every administrative account
- Just-in-time, time-bounded access for delivery work, with full audit logging
- Quarterly access reviews and immediate de-provisioning on personnel change
- Hardware-backed credentials for production systems where the platform supports it
Essential Eight alignment
We actively align with the Australian Signals Directorate's Essential Eight mitigation strategies — patching, application control, configuration of Microsoft Office macros, user application hardening, restricting administrative privileges, multi-factor authentication, patching operating systems, and regular backups. Maturity is measured against ML1 today, with a documented pathway toward ML2 controls. Evidence is available to clients under NDA.
SMB1001 attestation pathway
We are pursuing the SMB1001 Bronze and Silver attestation pathways, scheduled to land in the same window as the public launch of the Cyber arm in mid-2026. This gives buyers a recognisable signal of cyber maturity without the cost or complexity of ISO 27001-class attestation.
Vendor and sub-processor risk
Every third-party processor — hosting, AI inference, scheduling, payments, communications, analytics — is reviewed before adoption against:
- Their data-handling, retention, and training-on-input policies
- Jurisdiction and cross-border transfer posture
- Security certifications and attestation reports (SOC 2, ISO 27001, etc.)
- Breach notification commitments and incident-history transparency
The current list of sub-processors is published as part of the Data Processing Addendum at /dpa and updated when material changes occur.
Logging, monitoring, and integrity
- Immutable, append-only audit trails for engagement-critical operations (signing, payment, document generation)
- Anomaly detection on authentication and administrative actions
- Generated artefacts (PDFs, contracts, invoices) include SHA-256 content hashes and verification URLs
- Operational logs are retained for ninety days and reviewed during incident response
Application security
- Strict Content Security Policy and security headers across the public site (HSTS, X-Frame-Options DENY, Referrer-Policy strict-origin-when-cross-origin, Permissions-Policy zeroing camera/microphone/geolocation/payment)
- Input validation at every API boundary, with explicit length and format constraints
- Rate limiting on lead capture and AI endpoints to defend against abuse
- Dependencies updated on a regular cadence with vulnerability scanning in CI
- Code reviews on every change; production deploys are gated and reversible
AI inputs, outputs, and training
The lab tools generate output via third-party AI inference providers. We choose providers that contractually commit to not training on customer inputs by default and that retain inputs only for short windows (typically thirty days or less) for abuse-monitoring purposes. Inputs are minimised: we ask visitors to keep PII, customer data, and credentials out of lab tools.
Output filtering is in place to reduce the risk of harmful or off-topic responses. We do not claim AI infallibility — outputs are illustrative and require human judgement before action.
Incident response and breach notification
We maintain a written incident response plan covering identification, containment, eradication, recovery, and post-incident review. The plan is rehearsed at least once per year. Where an incident meets the threshold for the Notifiable Data Breaches scheme under Part IIIC of the Privacy Act 1988 (Cth), we notify affected individuals and the Office of the Australian Information Commissioner (OAIC) within the statutory window.
Suspected incidents may be reported to security@eigenra.com. We acknowledge within twenty-four hours and provide a substantive update within seventy-two hours.
Vulnerability disclosure
We welcome responsible disclosure from security researchers and the public. Please email security@eigenra.com with:
- A clear description of the issue and the affected URL or component
- Steps to reproduce
- The impact you believe the issue could have
- Your preferred contact and credit preference
In return we commit to: acknowledging your report within forty-eight hours, providing substantive updates as the issue is investigated, fixing valid issues without unreasonable delay, and crediting you in any public discussion of the fix unless you prefer otherwise. Please do not disclose the issue publicly until we've had a reasonable chance to respond.
Business continuity
Engagement-critical systems are configured with automated backups, region failover where available, and documented restoration procedures. We aim for an RPO of one hour and an RTO of four hours for client-facing services. Founder-key-person risk is mitigated by documentation, paired delivery, and contractual succession terms in client agreements.
People and training
Everyone with access to client data is contractually bound to confidentiality, completes security training before access, and receives recurrent training annually. Background checks are conducted in line with Australian standards before access to client data is granted.
Security contact
Security incidents and vulnerability disclosures: security@eigenra.com
Privacy enquiries: privacy@eigenra.com
General contact: /contact