SECURITY AND INCIDENT SCHEDULE

Effective Date: 24 August 2026
Version: 1

This Schedule forms part of Henry's standard Agreement and describes the technical and organisational measures that Henry AI (Pty) Ltd, registration number 2023/620906/07, trading as Henry, Henry AI, Henry Ingest, Henry Insights and Henry Exchange (Henry), applies to Personal Information in covered Henry systems, including Tenant Data and Henry Lead Data. It must be read with the Terms of Service, Privacy Policy, Operator Agreement, Service Level Agreement, Suboperator List, Retention, Deletion and De-identification Schedule, International Transfer and Recipient Register and applicable Product and Processing Schedule. References below to Tenant Data describe the standard customer-data controls and apply to Henry Lead Data and other Personal Information held in the same covered systems to the extent relevant to the processing and Henry's legal role.

This Schedule states Henry's standard controls. It does not represent that Henry holds a certification unless an applicable document or signed Enterprise Annex expressly confirms the current certification and its scope.

Standard and Enterprise arrangements: The standard position described in this document applies unless a signed Enterprise Annex expressly varies an eligible, identified contractual matter. Where legally and operationally available, any enhanced or non-standard scope, service level, support, infrastructure, assurance, reporting, implementation or other commitment must be separately requested, assessed, approved and priced under the Enterprise Agreement. An Enterprise Annex cannot alter statutory rights or mandatory legal obligations.

1. Scope and Security Standard

1.1. Henry will maintain appropriate, reasonable technical and organisational measures designed to preserve the confidentiality, integrity and availability of Personal Information in covered Henry systems and address reasonably foreseeable internal and external risks.

1.2. Controls apply according to the nature of the information, processing, system and risk. A control may be implemented by Henry or by a contracted infrastructure provider whose service Henry uses to deliver the relevant function.

1.3. Henry may replace a control with an alternative that does not materially reduce the overall protection of Tenant Data. A Tenant-specific algorithm, customer-managed key, dedicated environment, penetration-test cadence, recovery objective or certification applies only where stated in a signed Enterprise Annex and selected in the Online Order Record.

1.4. A material control substitution, exception, customer-specific security representation, audit commitment, certification statement, recovery objective or production-security change requires Henry's documented internal compliance and control-owner approvals and review by appropriately qualified external legal or compliance counsel before approval. No oral statement, meeting, demonstration, questionnaire, proposal, email or individual representative's approval creates or varies such a commitment.

2. Governance and Personnel

2.1. Henry will:

• assign responsibility for information security and privacy;
• maintain written policies proportionate to its systems and risks;
• perform and record a security risk assessment at least annually and after a material architecture or threat change;
• require personnel with access to Tenant Data to accept confidentiality and acceptable-use duties;
• require security, privacy, acceptable-use and incident-reporting training through Sprinto before production access, annually thereafter and after a material policy change; and
• maintain an incident-response process and escalation contacts.

2.2. Personnel access ends within eight Business Hours after departure and is changed promptly after a material role change. Material access changes follow an authorised joiner, mover and leaver process.

3. Identity and Access Control

3.1. Henry uses unique user identities for administrative access and prohibits shared privileged accounts except for a controlled emergency account whose use is logged and reviewed.

3.2. Henry applies role-based access and least privilege. Access to Tenant Data is limited to personnel who require it for service operation, support, security, legal compliance or a documented instruction.

3.3. Multi-factor authentication is required for personnel access to Microsoft 365, GitHub, AWS, Google Cloud, Azure, Supabase administration, Zoho One and WorkDrive, Tailscale and other covered production or administrative systems. Administrator and production access must use Tailscale. Privileged access is approved, logged and time-bounded where technically supported.

3.4. Henry reviews and documents user and privileged access at least annually and removes access that is obsolete, excessive or unexplained.

3.5. Content access for support or investigation must be approved, reasonably necessary, minimised, attributable to an individual, routed through Henry's controlled access path and subject to confidentiality and logging where supported. Henry does not represent that every system provides just-in-time access.

3.6. Tenant administrators control their Users, roles, source permissions and recipient configuration. Henry does not override an authorised Tenant configuration except to protect the Service, comply with law or correct a confirmed security issue.

4. Cryptography and Tenant Separation

4.1. Henry encrypts, or contractually uses provider services that encrypt, Tenant Data transmitted over public networks using current industry-standard transport protection.

4.2. Tenant Data in covered production databases, object stores and protected backups is encrypted at rest using the relevant provider's managed encryption unless a Product Schedule or signed Enterprise Annex identifies an exception.

4.3. Production credentials, tokens and secrets are stored only in approved Supabase, AWS, GitHub or Zoho Vault facilities. Apple Passwords may be used by an authorised director for the director's individually assigned credentials. Secrets may not be stored in source code, ordinary documents, email, chat or another unapproved password store.

4.4. The standard Service uses logical access controls to separate Tenant environments and records. It does not include dedicated physical infrastructure or a customer-managed encryption key unless stated in a signed Enterprise Annex.

5. Secure Operations

5.1. Henry maintains proportionate controls for asset and configuration records, authorised system changes, malware and abuse prevention, event logging, monitoring, vulnerability handling and supplier review.

5.2. Material production changes require authorised review, testing proportionate to risk and a rollback or mitigation approach where reasonably practicable. Emergency security changes may use an expedited process and must be documented after implementation.

5.3. Henry runs automated tests, dependency scanning, secret scanning, static analysis and applicable infrastructure checks on every pull request and requires independent peer approval before production merge. Henry targets remediation or a documented compensating control within seven calendar days for a validated critical risk, 30 calendar days for a validated high risk, 90 calendar days for a validated medium risk and 180 calendar days for a validated low risk. A different period may apply where remediation would create greater risk, a provider controls the fix, or no safe fix exists; Henry will document the reason, owner, expiry and interim control. Henry commissions an independent external penetration test at least annually.

5.4. Henry records security-relevant access and events where supported. Authentication, administrator, access-change, deployment, production and security audit logs are protected against ordinary alteration and retained for at least 12 months, with at least 90 days immediately searchable and the remainder in protected archive storage. Ordinary debugging and application-performance logs are retained for 90 days unless a shorter minimisation period or longer incident, dispute, legal-hold, fraud, PAIA, POPIA or contractual evidence period applies. Logs must not intentionally contain secrets, authentication tokens or unnecessary sensitive content.

5.5. Henry will not place substantive Tenant content in development or test environments unless reasonably necessary, authorised and protected to a standard appropriate to the data. De-identified or synthetic data is preferred.

5.6. A production change affecting an approved security or ISMS control must reference the applicable risk assessment, compliance decision, technical approval, test evidence and rollback plan. Production deployment must remain blocked while a required approval is missing or an internal compliance hold is active.

6. Backup, Continuity and Recovery

6.1. Henry may create redundant, replication, backup and recovery copies reasonably required for service resilience. Those copies are encrypted where covered by Section 4, access-restricted and used only for continuity, security and recovery.

6.2. Henry maintains standard backup and recovery processes for covered production data under its control in Supabase and Amazon S3 and tests a material restoration process at least every six months. A test may use representative rather than complete Tenant Data. Zoho WorkDrive content is governed by Zoho's configured service and retention controls and is not included in the standard Supabase/S3 restoration commitment.

6.3. The standard Service has the target RPO of twenty-four ordinary hours and target RTO of twenty-four Business Hours stated in the Service Level Agreement for covered Supabase and Amazon S3 production data under Henry's control. The RPO is measured as an elapsed data-loss window. The RTO runs only during Business Hours and pauses outside Business Hours. They are service objectives, not a promise of record-level historic-state recovery or permanent archival. Any stricter product-specific RPO/RTO, active-active, immutable-backup or customer-selected recovery commitment must be stated in a signed Enterprise Annex.

6.4. Deletion-pending backups are isolated from ordinary use. If a backup is restored, Henry will reapply applicable deletion instructions and access restrictions.

7. Security Incidents

7.1. A Security Compromise has the meaning in the Privacy Policy. Automated security and availability monitoring operates continuously. Human triage and response operate during Business Hours unless a separately documented on-call service applies. Henry will maintain procedures to detect, triage, contain, investigate, remediate and learn from suspected security events. Statutory or Operator notification duties are not postponed merely because an ordinary support clock is paused.

7.2. Where Henry acts as Operator, it will notify the affected Responsible Party immediately after it has reasonable grounds to believe that Personal Information was accessed or acquired by an unauthorised person. No contractual materiality or harm threshold applies to this Operator notice duty. Henry will not delay initial notice solely because the investigation is incomplete.

7.3. Available information may be supplied in phases and may include:

• the nature and approximate time of the event;
• affected systems, information categories and known Data Subjects;
• likely consequences;
• containment, mitigation and recovery steps;
• recommended Tenant actions; and
• Henry's incident contact.

7.4. Henry will preserve material evidence, keep an incident record, reasonably assist the Responsible Party's assessment and notifications, and provide a proportionate root-cause and corrective-action summary after a material incident. A notice or status communication is not an admission of liability.

7.5. The Tenant remains responsible for maintaining current incident contacts and making notifications required of it as Responsible Party. It must notify Henry immediately of a suspected credential, User, connector or Henry Lead Data compromise within its control.

8. Suppliers and Transfers

8.1. Henry performs and records risk-based diligence through Sprinto before appointing a material Suboperator and at least annually thereafter. The review covers the contract or DPA, assurance, information, purpose, role, countries, onward transfers, retention, AI settings, incident duties and deletion, and requires written confidentiality, purpose, security, incident, assistance and deletion obligations appropriate to the delegated processing.

8.2. Provider identities and change rights appear in the Suboperator List. Recipient, country, data and transfer information appears in the International Transfer and Recipient Register.

8.3. Henry remains responsible for performance of its Operator duties when using a Suboperator, subject to the lawful liability limits in the Agreement.

9. Assurance and Shared Responsibility

9.1. Henry will make its then-current standard assurance information available to a compliant Tenant under appropriate confidentiality restrictions. Standard evidence and reasonable written questions must be used before a focused independent audit is requested under the Operator Agreement.

9.2. Security is shared as follows:

9.3. A party's shared responsibility does not excuse its own obligations under law or the Agreement.

10. Changes and Contact

10.1. Henry may update controls to address technology and risk, provided the overall protection of Tenant Data is not materially reduced during a paid fixed Subscription Period. A materially adverse ordinary change applies on renewal; an urgent legal or security change may apply earlier to the extent reasonably necessary.

10.2. Security concerns must be sent to legal@henryai.co.za. Do not include passwords, secrets or unnecessary identity documents in an unsecured message.

END OF SECURITY AND INCIDENT SCHEDULE