Enterprise Security Addendum

This Enterprise Security Addendum ("ESA") sets out the security requirements and obligations applicable to the ZynReach services provided to enterprise customers.

This Addendum is intended to set out:

This Addendum forms part of the commercial agreement between ZynReach and the customer when it is incorporated into, or expressly referenced in, an Order Form, Master Services Agreement, or similar agreement.

• ZynReach's security framework.
• Technical and organizational measures.
• Access management.
• Data protection.
• Encryption.
• Infrastructure security.
• Vulnerability management.
• Incident management.
• Business continuity.
• Backup and disaster recovery.
• Management of third parties and Sub-processors.
• Customer security requirements.
• Incident cooperation.
• Audit and evidence of compliance.

This Addendum applies to the ZynReach services specified in the agreement or Order Form.

It does not automatically extend to:

unless otherwise agreed in writing.

• Third-party services not controlled by ZynReach.
• Customer systems.
• User devices.
• Customer networks.
• Integrations managed by the customer.
• External applications.

For the purposes of this Addendum:

Security Incident means a confirmed or reasonably suspected security event that results in, or may result in, unauthorized access, unauthorized loss or alteration of data, unauthorized disclosure, or a material disruption to the Service.

Personal Data means personal data as defined under applicable law.

Customer Data means the data provided by the customer or its users to ZynReach, or generated on the customer's behalf through use of the Services.

Sub-processor means a third party that processes Customer Data on behalf of ZynReach under the relevant contractual relationship.

Security Controls means the technical, organizational, and administrative controls used by ZynReach to protect the Services.

ZynReach is committed to maintaining a security program appropriate to the nature of the Services and the risks associated with them.

The program is designed to protect:

This does not mean that ZynReach guarantees that the Services will be immune to all threats or security incidents.

• Confidentiality.
• Integrity.
• Availability.
• Operational resilience.

ZynReach seeks to operate a structured information security management program that includes, depending on the nature and scale of the Services:

• Security policies.
• Risk assessments.
• Asset management.
• Access management.
• Vulnerability management.
• Security monitoring.
• Incident management.
• Business continuity.
• Vendor management.
• Training and awareness.

ZynReach maintains clear management responsibility for its security program.

The Company defines:

• Responsibilities.
• Authorities.
• Escalation procedures.
• Operational risk ownership.
• Review mechanisms.

ZynReach assesses security risks periodically or upon material changes to:

The results of risk assessments may be used to prioritize security controls.

• The Services.
• Infrastructure.
• Threats.
• Processes.
• Legal requirements.

ZynReach maintains security policies and procedures appropriate to the Services.

These are reviewed periodically and upon material changes.

ZynReach applies appropriate procedures to manage the security of personnel and staff who have access to sensitive systems.

These procedures may include:

• Appropriate pre-employment screening where permitted by law.
• Confidentiality agreements.
• Security training.
• Defining access privileges.
• Access termination procedures.

ZynReach works to provide appropriate security awareness to personnel whose roles require it.

Topics may include:

• Protection of credentials.
• Phishing.
• Data protection.
• Incident management.
• Device security.
• Social engineering.

ZynReach applies the principle of Least Privilege, whereby access is granted only to the extent necessary to perform assigned tasks.

ZynReach uses appropriate controls to manage access based on job role.

Access to systems and data is restricted according to need.

ZynReach uses multi-factor authentication for systems and accounts that require a heightened level of protection, based on risk and the technical design of the Service.

Access privileges to sensitive systems are reviewed periodically or upon material changes in roles or responsibilities.

When an employee's or contractor's need for access ends, access is revoked or modified in accordance with ZynReach's internal procedures.

Accounts with elevated privileges are subject to appropriate additional controls, which may include:

• MFA.
• Privileged Access Controls.
• Logging.
• Access Review.
• Segregation of Duties.

ZynReach applies appropriate procedures to protect:

Storage of sensitive credentials in an inappropriate manner is prohibited.

• Passwords.
• API Keys.
• Tokens.
• Secrets.
• Encryption keys.

ZynReach uses appropriate encryption to protect data in transit over public networks, in accordance with the technical design of the Service.

ZynReach uses appropriate means to protect stored data, depending on the nature of the data and the technical architecture.

Encryption keys are managed in accordance with appropriate procedures to protect:

• Confidentiality.
• Access.
• Key lifecycle.
• Unauthorized use.

ZynReach uses appropriate technical controls to segregate customer data and environments in accordance with the platform's design.

No customer may access another customer's data through normal use of the Service.

ZynReach integrates appropriate security practices into the software development lifecycle.

These may include:

• Secure Coding.
• Code Review.
• Dependency Management.
• Security Testing.
• Vulnerability Management.
• Change Management.

ZynReach seeks to integrate security requirements into the following stages:

• Design.
• Development.
• Testing.
• Deployment.
• Operation.

Significant code changes are subject to appropriate review processes based on the level of risk.

ZynReach works to identify and manage software components and dependencies used in the Services.

Dependencies may be scanned for known vulnerabilities.

ZynReach applies an appropriate process:

• To detect vulnerabilities.
• To assess risk.
• To prioritize remediation.
• To remediate vulnerabilities.
• To verify fixes.

Vulnerabilities may be classified according to their severity level, such as:

Remediation timeframes may vary depending on severity, complexity, and impact.

• Critical.
• High.
• Medium.
• Low.

ZynReach may conduct appropriate security testing, such as:

depending on the nature of the Service and its risks.

• Vulnerability Scanning.
• Security Testing.
• Penetration Testing.
• Application Security Testing.

Where appropriate, ZynReach provides a mechanism for the responsible reporting of security vulnerabilities.

Researchers must comply with any scope and rules established by ZynReach.

ZynReach maintains appropriate security and operational logs to support:

• Incident detection.
• Investigation.
• Troubleshooting.
• Auditing.
• Monitoring.

ZynReach uses appropriate monitoring tools to detect:

• Abnormal activity.
• Unauthorized access attempts.
• Security threats.
• Performance issues.
• Outages.

Appropriate controls are applied to protect logs from:

• Unauthorized modification.
• Unauthorized deletion.
• Unauthorized access.

ZynReach maintains a security incident management program that includes:

• Detection.
• Triage.
• Containment.
• Eradication.
• Recovery.
• Post-Incident Review.

Upon confirmation of a Security Incident affecting Customer Data, ZynReach will notify the customer in accordance with what is set out in:

ZynReach uses reasonably available information to provide a useful notification.

• The DPA.
• The Agreement.
• Applicable law.

The incident notice may include, depending on the information available:

The notice is not required to include unconfirmed information or information that could hinder the investigation or increase security risk.

• A general description of the incident.
• The date or period of the incident.
• The nature of the impact.
• The affected categories.
• Measures taken.
• Corrective measures.
• Appropriate contact information.

ZynReach cooperates reasonably with the customer in investigations relating to a security incident affecting Customer Data.

The scope of cooperation is subject to:

• The contract.
• The DPA.
• Applicable law.
• Security constraints.

ZynReach establishes appropriate channels for escalation and communication regarding security incidents.

These channels may vary depending on the customer tier and service.

ZynReach maintains appropriate procedures to support the continuity of critical services and operations.

ZynReach maintains appropriate disaster recovery plans in accordance with the nature of the Services.

These may include:

• System restoration.
• Data restoration.
• Failover.
• Recovery Procedures.

ZynReach uses appropriate backup mechanisms for services that require them.

Controls may include:

• Encryption of backups.
• Access control.
• Monitoring.
• Restoration testing.

In accordance with its internal practices, ZynReach conducts appropriate tests or exercises to verify the effectiveness of recovery procedures.

Material changes to infrastructure and services are subject to appropriate change management processes.

These may include:

• Impact assessment.
• Review.
• Testing.
• Approval.
• Documentation.
• Rollback plan.

Where ZynReach relies on Cloud or Data Center providers, the Company relies on the security controls provided by those providers, in addition to the controls that fall within ZynReach's own responsibility.

ZynReach's responsibility does not extend to controls that fall exclusively under the control of the infrastructure provider.

ZynReach uses appropriate cloud service providers based on the requirements of the Service.

Vendors and their associated controls are assessed in accordance with applicable procedures.

Depending on the technical architecture, ZynReach uses controls such as:

• Firewalls.
• Network Segmentation.
• Access Controls.
• Traffic Monitoring.
• Security Monitoring.

ZynReach applies appropriate procedures to protect devices used to access corporate systems.

These may include:

• Security updates.
• Device encryption.
• Access management.
• Malware protection.
• Appropriate monitoring.

ZynReach applies appropriate procedures to assess the security risks of vendors that may have access to:

• Systems.
• Data.
• Infrastructure.

ZynReach may use Sub-processors in accordance with the DPA and the Sub-processor Policy.

ZynReach remains contractually responsible to the customer for its processing obligations to the extent set out in the DPA.

ZynReach may add or replace Sub-processors in accordance with the notification and objection mechanism set out in the DPA.

ZynReach retains data in accordance with applicable retention policies and relevant agreements.

Following termination of the Service, Customer Data is handled in accordance with:

• The DPA.
• The Terms of Service.
• The Data Retention & Deletion Policy.
• Legal requirements.

ZynReach uses appropriate technical controls to reduce the risk of unauthorized cross-access between customer data sets.

ZynReach may use appropriate technical tests to verify isolation controls, depending on the design of the Service and the associated risks.

ZynReach seeks to consider privacy and security during the design and development of the Services where appropriate.

ZynReach seeks to minimize the collection and processing of data to the extent appropriate for the purposes of providing the Services.

The customer acknowledges that the security of the Service is a shared responsibility.

The customer remains responsible for:

• Its accounts.
• Its users.
• Passwords.
• MFA.
• Devices.
• Networks under its control.
• Integrations.
• Permission configurations.
• The data it chooses to enter into the Service.

The security measures applied by ZynReach do not mean that the customer is relieved of its own security responsibilities.

The customer must take appropriate measures proportionate to the risks specific to its environment.

The customer must:

• Create accounts for authorized users.
• Deactivate accounts that are no longer required.
• Review permissions.
• Protect login credentials.
• Prevent unauthorized account sharing.

When using the API, the customer is responsible for:

• Protecting API Keys.
• Protecting Secrets.
• Applying appropriate permissions.
• Monitoring API usage.
• Respecting Rate Limits.

ZynReach bears no responsibility for security risks arising exclusively from:

• Integration misconfiguration.
• Customer systems.
• Third-party accounts.
• Services outside ZynReach's control.

Enterprise customers may request reasonable information regarding ZynReach's security controls, in accordance with the applicable plan, contract, and confidentiality rights.

Depending on the nature of the relationship, ZynReach may provide:

subject to what is permitted by confidentiality and commercial security considerations.

• Security Questionnaire.
• Security Overview.
• Policy Documents.
• Certificates.
• Audit Reports.
• Compliance Evidence.

Where ZynReach holds valid independent audit reports or certifications, these may be provided to the customer subject to applicable restrictions.

The provision of any report or certification shall not be construed as a guarantee that the customer will be compliant with all of its legal requirements.

The customer may not conduct a direct on-site audit of ZynReach's systems without prior written consent, unless mandatory law grants such a right.

Any audit must be:

• Reasonable.
• Limited in scope.
• Related to the Services.
• Non-disruptive to the security or stability of the Service.
• Free of unnecessary disclosure of trade secrets.

Depending on the circumstances, ZynReach may satisfy audit requests through:

• Independent reports.
• Security questionnaires.
• Security documentation.
• Certifications.
• Written responses.
• Summaries of independent assessments.

The customer bears the costs of its own audit, unless the contract provides otherwise.

Where the customer's request requires a special audit or additional resources from ZynReach, reasonable fees may be agreed in advance.

The customer must maintain the confidentiality of all information it obtains during any assessment or audit.

An audit must not result in:

• Service disruption.
• Disclosure of other customers' data.
• Unnecessary disclosure of trade secrets.
• Weakening of security controls.
• Circumvention of protective measures.

The customer may not conduct Penetration Testing or Security Scanning of ZynReach's systems without prior written authorization.

Where the customer discovers a potential vulnerability, it must report it through the security channel designated by ZynReach, rather than exploiting it or publishing its details prior to coordination.

Where ZynReach uses Cloud or Data Center providers, it relies on the physical and security controls provided by those providers, in addition to the controls that fall under ZynReach's own responsibility.

ZynReach uses appropriate means to protect the communications and interfaces used to deliver the Services.

ZynReach retains security and operational logs for the period it deems appropriate in accordance with:

• Legal requirements.
• Security needs.
• Internal policies.
• The design of the Service.

Access to sensitive systems may be logged and monitored for purposes of:

• Security.
• Investigation.
• Auditing.
• Compliance.

The parties acknowledge that no technical system can be guaranteed to be protected from all risks.

No statement in this Addendum constitutes a guarantee of:

• The absence of any breach.
• The absence of any vulnerability.
• 100% Service availability.
• The absence of any data loss under all circumstances.

ZynReach seeks to manage its services in accordance with the legal and regulatory requirements applicable to it.

The customer remains responsible for the regulatory requirements specific to its own business.

Where ZynReach acts as a Processor of personal data, this Addendum must be read together with the DPA.

In the event of a conflict relating to the processing of personal data, the provisions of the DPA shall govern.

General rights relating to the use of the Services are governed by the Terms of Service or the applicable commercial agreement.

The customer and its users must comply with the Acceptable Use Policy.

ZynReach may take action against use that poses a security risk.

The management of Sub-processors is governed by the Sub-processor Policy and the DPA, as applicable.

ZynReach maintains an appropriate channel for receiving security reports.

The customer must use the channels specified in the agreement, the Trust Center, or the official website.

Neither party is obligated to disclose confidential or sensitive information beyond what is reasonably required to address the incident.

Certain information may be delayed or restricted where immediate disclosure would:

provided that the appropriate information is provided once it becomes possible to do so.

• Harm the investigation.
• Increase risk.
• Allow exploitation of the vulnerability.
• Violate the law.

ZynReach may cooperate with competent legal or regulatory authorities where legally required to do so.

Where ZynReach receives a legal request for access to customer data, it will be handled in accordance with applicable law, the DPA, and the applicable agreement.

The location of data processing or storage is determined in accordance with the applicable plan, agreement, or available Data Residency options.

No specific storage location should be assumed unless expressly stated.

ZynReach may modify security controls where necessary to:

Ordinary operational security changes do not constitute a breach of the agreement merely because they alter how a control is implemented.

• Address a new threat.
• Improve security.
• Update technology.
• Comply with the law.

ZynReach may implement urgent security updates without prior notice where necessary to protect the Services.

ZynReach works to maintain appropriate plans for the continuity of critical operations and services.

Where specific objectives such as:

are to apply, they must be expressly specified in the SLA or the commercial agreement.

Any values not contractually specified shall not be considered a guaranteed commitment.

• RTO.
• RPO.

ZynReach may apply temporary exceptions to certain operational procedures where necessary for technical or security reasons, provided that such exceptions are managed in accordance with appropriate internal procedures.

ZynReach may accept certain residual risks where the cost of remediation is disproportionate to the level of risk, in accordance with its internal risk management framework.

This Addendum is reviewed periodically or upon:

• A material change to the Services.
• A significant legal change.
• A material change in the threat model.
• The occurrence of a material incident.

No amendment to this Addendum shall be considered effective as a contractual obligation on the customer except in accordance with the amendment mechanism set out in the agreement.

In the event of a conflict:

this order applies only to the matter in conflict.

• Mandatory law.
• The signed commercial agreement.
• The DPA, with respect to personal data.
• The SLA, with respect to service levels.
• This Enterprise Security Addendum.
• General policies.

This Addendum does not, in itself, increase or alter the limits of liability set out in the commercial agreement unless the agreement expressly provides otherwise.

No reference in this Addendum to a security practice or control shall be construed as an independent warranty beyond the express contractual obligations.

All non-public security information provided to the customer under this Addendum is considered confidential, unless it is lawfully publicly available or the contract provides otherwise.

The customer may not publish or share:

except pursuant to an authorization or legal obligation.

• Penetration testing results.
• Vulnerability reports.
• System architecture.
• Technical keys or secrets.
• Security Architecture.
• Incident information.

The parties may agree on additional addenda, such as:

• Security Requirements Schedule.
• Data Residency Addendum.
• Incident Notification Schedule.
• Business Continuity Schedule.
• Customer-Specific Security Controls.
• Compliance Addendum.

Certain Enterprise agreements may include additional security requirements.

These requirements shall not be binding on ZynReach unless:

• They are agreed in writing.
• Their scope is defined.
• Responsibility for their implementation is defined.
• Any additional fees or resources required are defined.

Where the customer requests special security controls that fall outside the standard Service, ZynReach may evaluate the request and determine:

• Feasibility of implementation.
• Cost.
• Timeline.
• Operational impact.
• Contractual obligations.

No security questionnaire, response to a Questionnaire, presentation, or sales call shall be construed as a modification of this agreement.

No additional obligations shall become effective unless agreed in writing by the authorized representatives of both parties.

The customer is responsible for determining its own security and compliance requirements prior to subscribing.

ZynReach is bound only by the requirements it has expressly accepted contractually.

The parties acknowledge that security in a SaaS environment relies on a shared responsibility model.

ZynReach is responsible for the controls within its own scope of control, while the customer is responsible for the controls, systems, and data within its scope of control.

The failure of either party to enforce any provision of this Addendum shall not constitute a waiver of that provision.

If any provision of this Addendum becomes invalid or unenforceable, this shall not affect the remaining provisions.

This Addendum is governed by the governing law specified in the commercial agreement between ZynReach and the customer.

In the absence of a contractual provision, the applicable law shall apply in accordance with the applicable legal rules.

Disputes relating to this Addendum are subject to the dispute resolution mechanism set out in the commercial agreement.

This Addendum, together with the agreements to which it refers, represents the entire understanding between the parties regarding the security requirements set out herein.

The following table sets out the details of this document:

• Document name: Enterprise Security Addendum.
• Abbreviation: ESA.
• Company: Zyntra Digital.
• Platform: ZynReach.
• Website: zynreach.com.
• Version: 1.0.
• Effective date: August 31, 2026.
• Classification: Confidential / Enterprise.
• Owner: Security / Legal.
• Review: Periodically or upon a material change.
• Related documents: MSA / Terms of Service / DPA / SLA / Security & Trust Policy / Incident Response Policy / Sub-processor Policy.

Upon the incorporation of this Addendum into a written agreement or signed Order Form, both parties acknowledge that they have read its provisions, understood the obligations set out herein, and agreed to them.

• Zyntra Digital — Name, Title, Signature, Date.
• Customer — Company Name, Name, Title, Signature, Date.

This Addendum is designed to form part of the contractual security framework for ZynReach's services directed at enterprise customers.

No provision herein should be construed as an absolute guarantee of security, availability, or the absence of incidents.

The commercial agreement, DPA, and SLA, where applicable, set out the contractual obligations specific to each customer, while this document sets out the general security framework and the contractual security obligations expressly agreed upon.