Security Overview
En vigueur le 2026-06-21 · 2026-06-21
hey ema — Security Overview
1. Purpose, scope and status
1.1 What this document is
This Security Overview describes the technical and organisational security measures that Hey ema (operated by By Loci Pty Ltd) applies to protect Customer Data and Personal Information Processed within the Hey ema service. It is intended to help Customers and their security, privacy and procurement teams understand Hey ema's security posture during evaluation and throughout the relationship.
1.2 What this document covers
This document covers the production Hey ema service hosted on Amazon Web Services (AWS). It does not cover beta, preview or sandbox features (consistent with SLA §1), the Customer's own systems, or third-party services that the Customer connects to Hey ema outside Hey ema's control.
1.3 Relationship to other documents
This Security Overview should be read together with:
- the Data Processing Agreement (H3), in particular Annex II (the binding technical and organisational measures);
- the AI / Data Use Addendum (H4) (AI Processing, training-use position, and inference isolation);
- the Service Level Agreement (H8) (uptime, backup, RTO/RPO, post-incident review);
- the Sub-processor List (H7) (third parties that Process Customer Data);
- the Responsible Disclosure Policy (H14); and
- the Privacy Policy (H2) and the operational Data Breach Response Plan.
Where this document summarises a measure that is stated in binding form elsewhere, the binding document governs.
1.4 Status — informational vs incorporated
This document is provided for information. The legally binding security commitments are those in DPA Annex II and the rest of the MSA suite; nothing in this document is intended to create commitments beyond those.
1.5 Updates
Hey ema may update this document from time to time as its controls evolve, provided that the overall level of protection is not materially decreased (consistent with the standard in DPA Annex II).
2. Security governance and ownership
2.1 Hey ema operates a documented information security program owned by the Hey ema Engineering & Security function within By Loci Pty Ltd.
2.2 The program is built on a risk-based control framework aligned to ISO 27001 and SOC 2 (see §3), and is reviewed at least annually, including its policies, procedures and controls (consistent with DPA Annex II.A).
2.3 Security responsibilities are assigned to identified roles; security risks are tracked and remediated through a documented risk-management process.
2.4 Hey ema maintains records of Processing activities as required under the DPA (DPA §4.7).
3. Certifications and attestations
3.1 Hey ema's control framework is aligned to ISO/IEC 27001 and the SOC 2 Trust Services Criteria (Security, and where relevant Availability and Confidentiality).
3.2 SOC 2 Type II — Hey ema is aligned to the SOC 2 Trust Services Criteria but does not currently hold a SOC 2 Type II report.
3.3 ISO/IEC 27001 — Hey ema is aligned to ISO/IEC 27001 but is not currently certified.
3.4 Where independent audit reports or certificates exist, Hey ema makes the current report or certificate (and, where relevant, a bridge letter) available to Customers under NDA, and responds to reasonable security questionnaires, in accordance with the audit provisions of the DPA (DPA §9).
3.5
4. Hosting and infrastructure
4.1 Cloud provider. Hey ema is hosted on Amazon Web Services (AWS). AWS is engaged as a Sub-processor (see H7) and operates under its own extensive certifications (including ISO 27001, SOC 1/2/3, PCI DSS, and others) for the underlying infrastructure.
4.2 Regions. Production workloads currently run in a single AWS region — Australia (ap-southeast-2). Hey ema expects to deploy into additional regions (with regional routing) as its customer base grows.
4.3 Data residency. Hey ema does not currently offer customer-selectable data residency; all production Customer Data is hosted in Australia (ap-southeast-2). As Hey ema expands (in particular if it onboards a significant EU customer base), it expects to introduce regional routing/residency options consistent with the cross-border transfer mechanics in DPA §8.
4.4 High availability. Production services are deployed across multiple AWS Availability Zones within a region to support resilience (see §15 and SLA §6).
5. Encryption
5.1 In transit. All communications between Customers, Authorised Users, End Users and Hey ema, and between Hey ema's internal services where they traverse untrusted networks, are encrypted using TLS 1.2 or higher (consistent with DPA Annex II.C).
5.2 At rest. Customer Data and Personal Information stored by Hey ema are encrypted at rest using AES-256 or equivalent (consistent with DPA Annex II.C), including primary data stores, backups, and object storage.
5.3 Key management. Encryption keys are managed using AWS Key Management Service (or equivalent), with key rotation and separation of duties (consistent with DPA Annex II.C).
6. Identity and access control
6.1 Least privilege. Internal access to systems and Customer Data follows least-privilege and need-to-know principles, with role-based access control (RBAC) and default-deny configurations (consistent with DPA Annex II.B).
6.2 Authentication for staff. Staff access to production systems and administrative tools requires single sign-on (SSO) and multi-factor authentication (MFA) for all administrative access (consistent with DPA Annex II.B).
6.3 Access reviews and offboarding. Access is reviewed periodically, and access is de-provisioned promptly on staff offboarding or role change (consistent with DPA Annex II.B).
6.4 Customer-side access controls. Within Hey ema, Customers can configure their own access controls, including role permissions, optional MFA enforcement, and SSO / SAML (consistent with DPA Annex II.B).
7. Network security
7.1 Hey ema applies network segmentation between environments and tiers, with default-deny security groups and restricted ingress/egress (consistent with DPA Annex II.D).
7.2 A Web Application Firewall (WAF) and DDoS protection are applied at the edge (consistent with DPA Annex II.D and the CDN/WAF Sub-processor in H7).
7.3 Administrative access to infrastructure is restricted to authorised personnel over controlled paths, and is logged and monitored (see §11).
7.4 Anti-malware controls are applied on endpoints and on build/deploy infrastructure (consistent with DPA Annex II.D).
8. Secure development and change management
8.1 Hey ema follows a secure software development lifecycle (SDLC), including peer code review, version control, and separation of duties between development and deployment.
8.2 Change management. Changes to production are made through controlled CI/CD pipelines with automated testing and approval gates. Emergency changes follow a documented Emergency Maintenance process (consistent with SLA §3.2).
8.3 Security is considered through the development lifecycle, including dependency scanning, static analysis, and secrets-scanning in the pipeline.
9. Vulnerability management and patching
9.1 Hey ema operates a vulnerability management program with regular scanning of infrastructure, dependencies and container images, and timely remediation (consistent with DPA Annex II.D).
9.2 Vulnerabilities are triaged by severity and remediated on a risk-prioritised basis, with security-critical issues expedited. Hey ema does not commit to fixed remediation timeframes in this document.
9.3 Operating systems, managed services and third-party components are patched on a risk-prioritised basis, with security-critical patches expedited.
10. Penetration testing
10.1 Hey ema uses security testing (including vulnerability scanning and, from time to time, independent penetration testing) as part of its security program. Hey ema does not commit to a fixed testing cadence in this document.
10.2 Where an independent penetration test has been carried out, a summary report or attestation may be made available to Customers under NDA on request (consistent with DPA §9). Hey ema does not release the full unredacted report.
10.3 Findings are tracked to remediation through the vulnerability management process (§9).
11. Logging, monitoring and SIEM
11.1 Hey ema maintains centralised logging across application and infrastructure layers, with automated alerting on security-relevant events. Hey ema does not represent that it operates a 24/7 staffed security operations centre.
11.2 Security-relevant events are logged, retained, and protected against tampering.
11.3 Alerts feed the incident response process (§16).
12. Data segregation and multi-tenancy isolation
12.1 Hey ema is a multi-tenant SaaS service. Customer Data is logically separated between tenants, with controls designed to ensure one Customer cannot access another Customer's data (consistent with DPA Annex II.C).
12.2 Tenant isolation is enforced at the application and data layers through tenant-scoped access controls and identifiers.
12.3
13. AI inference isolation and data use
13.1 Hey ema's AI features are governed by the AI / Data Use Addendum (H4). This section summarises the relevant security controls; the binding position is in H4.
13.2 Inference isolation. Hey ema implements tenant isolation in AI inference paths, designed to prevent a Customer's prompts, contextual data, or AI Outputs from being exposed to other customers in real time (consistent with DPA Annex II.H and H4 §11.1).
13.3 No training on Customer Data except as permitted by H4. Hey ema does not use identifiable End User content for model training except as expressly permitted under the AI / Data Use Addendum (H4 §§4–5), which excludes the categories of Excluded Data in H4 §4.1 and requires De-identification/Aggregation to the standard in H4 §5 before any permitted Training Use. Customers may opt out of Training Use under H4 §8.
13.4 Model Providers. Where third-party Model Providers are used, they are engaged as Sub-processors (see H7) on terms that prohibit use of Customer Data to train Model Provider models for the benefit of third parties, and that limit retention to short abuse-monitoring windows, except where the Customer has expressly opted into other arrangements (consistent with H4 §11.2).
13.5 AI prompt and response metadata may be logged for audit and abuse-prevention purposes, with retention aligned to the Privacy Policy (consistent with DPA Annex II.H).
14. Personnel security
14.1 Screening. Hey ema conducts pre-employment background checks where lawful and appropriate to the role (consistent with DPA Annex II.F).
14.2 Confidentiality. Staff and contractors are bound by confidentiality obligations in their employment or engagement agreements (consistent with DPA §4.4 and Annex II.F).
14.3 Training. All staff complete privacy and security awareness training at least annually, with role-specific training for staff who Process Personal Information (consistent with DPA Annex II.F).
15. Business continuity and disaster recovery
15.1 Hey ema maintains documented business continuity and disaster recovery plans, tested at least annually (consistent with DPA Annex II.E).
15.2 Production services are deployed across multiple AWS Availability Zones to tolerate the loss of an Availability Zone (consistent with DPA Annex II.E and SLA §6).
15.3 Backups. Encrypted backups of production Customer Data are taken, tested, and retained in line with the DPA (backups deleted in the ordinary backup cycle, typically within 35 days — DPA §12.3; SLA §6.1).
15.4 RTO / RPO. For full-region production failure events, Hey ema's recovery objectives are:
- Recovery Time Objective (RTO): 4 hours
- Recovery Point Objective (RPO): 1 hour
these objectives mirror SLA §6.2.
16. Incident response
16.1 Hey ema maintains a documented incident response plan — see the operational Data Breach Response Plan and DPA Annex II.E.
16.2 Breach notification. In the event of a Personal Data Breach affecting Personal Information Processed on behalf of the Customer, Hey ema will notify the affected Customer in accordance with the DPA (without undue delay, and in any event within the timeframe in DPA §6, currently 24 hours of becoming aware), including the information described in DPA §6.2, and will cooperate with the Customer's own breach-notification obligations (DPA §6.3).
16.3 Post-incident review. For qualifying incidents, Hey ema provides a post-incident review / root-cause analysis on request, consistent with SLA §8.
16.4 The severity classification and target response times for support and security incidents are set out in SLA §5.2 (S1 includes a confirmed security incident or confirmed Personal Data Breach).
17. Responsible disclosure and vulnerability reporting
17.1 Hey ema welcomes reports from security researchers and Customers about suspected vulnerabilities. Our Responsible Disclosure Policy (H14) describes how to report issues, what we will do, and the rules for good-faith research.
17.2 Suspected vulnerabilities should be reported to security@heyema.com in accordance with that Policy. Hey ema does not currently offer monetary rewards (no bug bounty).
17.3 Hey ema asks reporters to allow a reasonable period to investigate and remediate before public disclosure, and not to access, modify or delete data belonging to others while testing.
18. Data deletion and return
18.1 Customers can export their Customer Data at any time using in-product export tools (consistent with SLA §6.3).
18.2 On termination or expiry, Customer Data is returned or deleted in accordance with DPA §12 (Customer may instruct return or deletion within 30 days; in the absence of instruction, deletion within a further 30 days; backups purged in the ordinary backup cycle), subject to any retention required by Applicable Law.
19. Sub-processors
19.1 Hey ema engages a limited set of Sub-processors to provide Hey ema. The current list, with each Sub-processor's purpose, the categories of Personal Information involved, processing location, and transfer mechanism, is maintained in the Sub-processor List (H7) (also incorporated at DPA Annex III).
19.2 Sub-processors are subject to due diligence before onboarding and periodic re-assessment, and are bound by data protection terms no less protective than the DPA (consistent with DPA §7.3 and Annex II.G). Customers can be notified of new or replacement Sub-processors and can object on reasonable data-protection grounds in accordance with DPA §7.2.
20. Shared responsibility
Security of the Hey ema service is a shared responsibility. In summary:
| Hey ema is responsible for… | The Customer is responsible for… |
|---|---|
| Security of the underlying platform, application, and AWS infrastructure configuration; encryption in transit and at rest; tenant isolation; backups and DR of the service; monitoring, vulnerability and incident management for the service. | Configuring Hey ema's available security controls (roles/RBAC, SSO/SAML, MFA enforcement); managing its own Authorised Users and promptly de-provisioning leavers; the security of the Customer's own devices, networks and credentials. |
| Making available the security features described in this document and the documentation. | Deciding what Customer Data and Personal Information to submit, and not submitting special-category/sensitive data except as permitted (DPA §3; H4 §4); obtaining any required lawful basis and providing End User notices (H4 §6.5). |
| Notifying the Customer of Personal Data Breaches per DPA §6. | Responding to data-subject requests as Controller (DPA §5), and meeting the Customer's own compliance obligations as Controller/deployer (DPA; H4 §10.3). |
| Operating Sub-processors under appropriate terms (DPA §7; H7). | Securing any third-party services or integrations the Customer connects to Hey ema. |
21. Contact
For security questions, due-diligence requests, certifications/reports under NDA, or to report a vulnerability, contact: security@heyema.com (see the Responsible Disclosure Policy). Privacy matters: privacy@heyema.com.
This Security Overview is provided for information and is consistent with, but does not expand or vary, the binding security commitments in the Hey ema Data Processing Agreement (Annex II) and the rest of the Hey ema MSA suite. Capitalised terms have the meanings given in the MSA, the DPA, the AI / Data Use Addendum, and the MSA and its Schedules.