Security & Trust Policy

ZynReach, as an enterprise platform for operations, growth, automation, and data management, is committed to implementing security and organizational practices and controls designed to protect customer information, user data, and platform resources from unauthorized access, unlawful use, unauthorized modification, loss, or disruption.

ZynReach's security philosophy is built on the principle: Security and Trust by Design

This means that security, trust, and data protection are treated as fundamental elements in the design and operation of the platform, not as later additions.

ZynReach applies a multi-layered approach that combines, depending on the nature of the service and environment:

• Infrastructure security.
• Data encryption.
• Identity and access management.
• The principle of least privilege.
• Multi-factor authentication.
• Continuous monitoring.
• Audit logging.
• Vulnerability management.
• Backup and recovery.
• Incident response.
• Vendor management.
• Data protection and privacy.
• Governance and accountability.

This policy aims to define the general principles and controls adopted by ZynReach to protect:

It also aims to clarify the responsibilities of ZynReach and the responsibilities of customers and users within a Shared Responsibility model.

• Customer data.
• Personal data.
• User accounts.
• Organizational data.
• Transaction and operational data.
• Documents and files.
• Integration data.
• System logs.
• Infrastructure.
• Systems and applications.
• Secrets and security keys.
• Confidential and commercial information.

This policy applies, to the extent applicable to the service, to:

• The ZynReach platform.
• Applications and application programming interfaces.
• Databases.
• Cloud infrastructure.
• Integration services.
• APIs.
• Authentication systems.
• Monitoring systems.
• Logging and audit systems.
• Backup systems.
• Support tools.
• Incident management systems.
• Vendors and sub-processors.
• Employees and contractors who have access to ZynReach environments.
• Data processed on behalf of customers.

ZynReach relies on the following principles:

4.1 Security by Design: Security requirements are taken into account during the design, development, and operation of services.

4.2 Least Privilege: Access is granted only to the extent required to perform the authorized function or task.

4.3 Defense in Depth: Protection does not rely on a single security control, but on multiple layers of controls.

4.4 Zero Trust Principles: Access to sensitive resources is handled on the basis of verification and authorization, not on default trust.

4.5 Accountability: Sensitive activities must be traceable and auditable wherever possible.

4.6 Privacy by Design: Data protection and privacy are taken into account when designing processes and services that handle personal data.

4.7 Continuous Improvement: Security controls and practices are subject to ongoing review and improvement.

ZynReach may classify information into the following levels:

The appropriate level of protection is determined based on the nature of the information and its associated risks.

• Public — information that may be disclosed to the public.
• Internal — information intended for internal use.
• Confidential — non-public business or operational information.
• Restricted — sensitive security or technical information.
• Highly Restricted — information whose disclosure could result in material security or business risk.

ZynReach treats customer data as one of the most important assets requiring protection.

Controls include, depending on the service and environment:

ZynReach personnel may not access customer data unless such access is necessary to perform a legitimate function, authorized, consistent with approved permissions, and subject to appropriate controls.

ZynReach notes that internal access to customer data is determined by role and is logged.

• Access control.
• Encryption.
• Activity logging.
• Segregation of duties.
• Access monitoring.
• Backup.
• Recovery procedures.
• Incident management.
• Vulnerability management.
• Infrastructure protection.

7.1 Data in Transit: Appropriate encryption protocols, including TLS, are used to protect data while it is transmitted between the user and the platform, or between systems and services that require a secure connection.

7.2 Data at Rest: ZynReach uses appropriate encryption methods to protect stored data, in line with the technical architecture of the service.

7.3 Backups: Backups are subject to appropriate security controls to protect data from unauthorized access or use.

The current Security page notes that ZynReach uses TLS in transit and standard encryption for data at rest.

ZynReach applies controls designed to verify that a user or system attempting to access a resource holds the appropriate authorization.

These controls may include:

ZynReach currently notes that RBAC/ABAC are applied to actions, with a full audit log of access to customer data.

• Authentication.
• Authorization.
• Role-Based Access Control (RBAC).
• Attribute-Based Access Control (ABAC).
• Multi-Factor Authentication.
• Session Controls.
• Privileged Access Management.
• Access Reviews.
• Audit Logging.

ZynReach supports multi-factor authentication (2FA/MFA) depending on the account level, plan, and function.

The current security page indicates that 2FA is available for every account, and is required for administrative and Enterprise roles, using TOTP.

Customers must:

• Protect authentication credentials.
• Not share verification codes.
• Use trusted authentication methods.
• Remove access credentials when a user leaves the organization.

ZynReach applies the principle: Access is granted based on business need.

A user or employee is not assumed to have unnecessary access to data or systems.

The privilege management process may include:

• Access request.
• Administrator approval.
• Role assignment.
• Granting of the privilege.
• Privilege review.
• Modifying it.
• Revoking it when no longer needed.

Access to sensitive systems and resources is subject to additional controls.

This includes, depending on the nature of the environment:

• Identification of authorized users.
• Segregation of duties.
• Activity logging.
• Review of privileges.
• Restriction of access.
• Use of strong authentication methods.
• Revocation of privileges when no longer needed.

Audit logs are considered a fundamental part of ZynReach's governance and security model.

Depending on the nature of the system and process, important activities are logged in a way that allows understanding of: Who — What — When — Where

That is:

ZynReach notes that platform actions, including record changes, approvals, logins, and settings, are logged within a searchable Audit Trail.

• Who performed the action?
• What action was taken?
• When was it taken?
• On which resource or record was it taken?

ZynReach aims to protect audit logs from unauthorized access, use, modification, or deletion, and audit logs are used for multiple purposes as follows:

• Protection against — unauthorized modification.
• Protection against — unauthorized deletion.
• Protection against — unauthorized access.
• Protection against — unlawful use.
• Used for purposes of — security.
• Used for purposes of — investigation.
• Used for purposes of — governance.
• Used for purposes of — troubleshooting.
• Used for purposes of — compliance.
• Used for purposes of — activity review.

ZynReach adopts practices designed to integrate security into the software development lifecycle.

These may include:

This does not mean that any piece of software can be guaranteed to be completely free of vulnerabilities.

• Security requirements review.
• Code review.
• Dependency scanning.
• Vulnerability scanning.
• Secrets management.
• Application testing.
• Change review.
• Version control.
• Separation of environments.

ZynReach uses practices to manage vulnerabilities and technical risks.

These may include:

The Security page indicates continuous Vulnerability Scanning and periodic third-party security assessments.

• Vulnerability discovery.
• Risk assessment.
• Prioritization.
• Remediation.
• Verification of the fix.
• Follow-up.
• Closure.

ZynReach conducts, depending on the scope of the service and environment, security tests and assessments aimed at identifying risks and improving controls.

These may include:

The results of a specific test are not considered a guarantee that the platform is free of all risk.

• Vulnerability Assessments.
• Security Testing.
• Third-Party Security Assessments.
• Security reviews.
• Tests related to infrastructure or the application.

ZynReach monitors systems and activities related to security and operations, using alerting mechanisms when unusual behavior or activity is detected.

The current security page notes continuous monitoring of infrastructure and access activity, with alerting on unusual behavior.

ZynReach maintains a framework for responding to security incidents.

This may include:

ZynReach notes that it maintains an Incident Response Plan, severity levels, escalation procedures, and customer notification processes consistent with applicable regulatory requirements.

• Detection — identifying the incident.
• Triage — initial assessment of the situation.
• Classification — determining the severity level.
• Containment — containing the impact.
• Investigation — investigation and analysis.
• Remediation — remediation.
• Recovery — restoring the service.
• Post-Incident Review — subsequent review.

If a security incident occurs that affects customer data, it is handled according to:

Not every technical alert or internal security event is considered an incident requiring customer notification.

Whether notification is required is determined based on an assessment of the incident and the applicable law or contract.

• The nature of the incident.
• Its scope.
• The severity level.
• Legal obligations.
• Contractual obligations.
• Applicable regulatory requirements.

ZynReach uses automated backup processes in line with the operational architecture of the service.

Backup objectives include:

ZynReach notes that it maintains regular automated backups and documented procedures for recovery and service restoration.

• Protecting data.
• Supporting recovery.
• Reducing the impact of incidents.
• Supporting service continuity.

ZynReach maintains procedures designed to support the restoration of services in the event of:

The existence of a Disaster Recovery Process is not a guarantee that all services will be restored within a specific time under all circumstances, unless expressly agreed in an SLA or Enterprise agreement.

• Failures.
• Technical incidents.
• Infrastructure issues.
• Security incidents.
• Impactful outages.

ZynReach seeks to maintain the continuity of essential services through:

Continuity objectives and service levels may vary depending on the plan, contract, and SLA.

• Contingency planning.
• Monitoring.
• Backup.
• Recovery procedures.
• Operational escalation.
• Incident management.

ZynReach relies on infrastructure and technology service providers to support the operation of the platform.

Controls include, depending on the environment:

The current Compliance page notes that customer data hosting is, by default, located in data centers within the United States, with regional options available for Enterprise plans as contractually available.

• Access control.
• Encryption.
• System monitoring.
• Configuration management.
• Vulnerability management.
• Backup.
• Activity logging.

ZynReach may use third parties to provide services necessary for operating the platform.

The categories currently published include:

ZynReach notes that the list of Sub-processors is updated in accordance with the DPA.

• Cloud Infrastructure.
• Email Delivery.
• Analytics.
• Customer Support.

ZynReach seeks to assess the risks associated with vendors and external services based on the importance of the service and the nature of the data that may be involved.

This may include:

• Security assessment.
• Privacy assessment.
• Contractual review.
• Service level review.
• Data protection requirements review.

ZynReach treats data protection as a fundamental element of trust.

When ZynReach acts as a data processor on behalf of the customer, the processing of data is subject, as applicable, to the DPA, the service agreement, and applicable laws.

ZynReach's current DPA provides for the processing of data based on the customer's documented instructions, with provisions relating to sub-processors, security measures, data subject rights, and international transfers.

ZynReach seeks not to collect or process information beyond what is necessary for the legitimate purposes of the service, wherever possible and appropriate.

The customer remains responsible for determining the type of data it enters into the platform and for ensuring it has the legal basis and authority necessary to process it.

Data retention periods are subject to:

Deleting data from the user interface does not necessarily mean that all backups associated with it are deleted at the same moment, as backups may be subject to specific technical retention cycles.

• The nature of the data.
• Service settings.
• The agreement.
• The DPA.
• Legal requirements.
• Recovery and backup needs.

When personal data is transferred across borders, ZynReach applies the appropriate legal safeguards in accordance with applicable law.

The current DPA provides for the application of appropriate safeguards when carrying out international transfers of personal data.

Employees and contractors who have access to sensitive information or systems are subject to appropriate controls depending on the nature of their roles.

These may include:

• Definition of responsibilities.
• Confidentiality agreements.
• Training.
• Privilege management.
• Access review.
• Revocation of access when no longer needed.

When an employee's or contractor's relationship ends, or their role changes, appropriate actions are taken to revoke or modify privileges in accordance with internal processes.

This is intended to prevent the continuation of unnecessary access to systems or data.

ZynReach supports integration with external systems and services, including APIs and Webhooks.

Credentials used for integrations must be protected in accordance with appropriate security practices.

ZynReach is not responsible for the compromise of an external account or system resulting from improper management of credentials by the customer or a third party.

Because ZynReach includes AI capabilities, AI Assistants, and AI Agents, intelligent systems are treated as part of the security and governance environment.

AI operations must, depending on the nature of the feature, be subject to the principles of:

ZynReach notes that AI Agents can perform actual actions, with human approval checkpoints and an audit log for every action.

AI outputs may not be interpreted as a final legal, financial, or security decision unless approved by the user or the authorized party.

• Access Control.
• Data Minimization.
• Human Oversight.
• Auditability.
• Approval Controls.
• Guardrails.
• Appropriate Authorization.

The security of the service is a shared responsibility between ZynReach and the customer.

ZynReach's responsibilities include, depending on the service, the following, while the customer's responsibilities include the following:

• ZynReach's responsibilities — Platform security.
• ZynReach's responsibilities — Infrastructure security.
• ZynReach's responsibilities — Protection of systems.
• ZynReach's responsibilities — Vulnerability management.
• ZynReach's responsibilities — Monitoring.
• ZynReach's responsibilities — Incident response.
• ZynReach's responsibilities — Backup.
• ZynReach's responsibilities — Protection of the technical infrastructure.
• Customer's responsibilities — Protecting login credentials.
• Customer's responsibilities — User management.
• Customer's responsibilities — Privilege management.
• Customer's responsibilities — Selecting authorized users.
• Customer's responsibilities — Protecting devices used for access.
• Customer's responsibilities — Protecting integration keys.
• Customer's responsibilities — Determining the data entered.
• Customer's responsibilities — Complying with laws related to its data.

ZynReach cannot control all risks present on the customer's devices, networks, or external systems.

The customer must therefore take appropriate measures, such as:

• Using up-to-date devices.
• Protecting accounts.
• Enabling MFA.
• Preventing account sharing.
• Using secure networks.
• Training staff.
• Monitoring users.

ZynReach encourages security researchers and customers to responsibly report potential security vulnerabilities.

The following must not be done:

The information necessary to help the security team understand and verify the issue must be provided.

Official reporting channel: security@zynreach.com

• Exploiting the vulnerability.
• Accessing customer data.
• Modifying data.
• Disrupting the service.
• Conducting broad testing without authorization.

The publication of this policy or any Security Documentation does not constitute authorization to perform any of the following on ZynReach systems:

Prior written authorization must be obtained before conducting any security testing that goes beyond normal, authorized use.

• Penetration Testing.
• Vulnerability Scanning.
• Exploitation.
• Load Testing.
• Reverse Engineering.

ZynReach seeks to organize its security program in line with frameworks and standards appropriate to the nature of its services. The website currently presents:

The Compliance page describes the scope of each framework separately.

• SOC 2 Type II — controls related to security, availability, and confidentiality, with independent audit within the stated scope.
• ISO 27001 — information security management practices compliant with/aligned with the ISO 27001 framework as described in the published materials.
• GDPR — data processing practices designed to support relevant GDPR requirements.
• CCPA — practices related to the rights and disclosures of the California Consumer Privacy Act.

Mentioning any standard, framework, or law does not mean that using ZynReach automatically renders the customer compliant with all requirements of that standard or law.

Compliance also depends on:

• How the customer uses the service.
• The type of data.
• The location of the parties.
• The industry sector.
• Internal procedures.
• The legal basis for processing.
• System settings.

As a matter of communications policy, ZynReach is committed to ensuring that security and compliance claims are demonstrable and clearly scoped.

The following terms should not be used interchangeably: Certified, Compliant, Audited, Aligned, Ready.

The following must be specified:

This is particularly important because the ZynReach website currently uses different phrasings such as SOC 2 Type II, ISO 27001 aligned, and GDPR-ready.

• The entity that issued the certificate or report.
• The scope of the audit.
• The time period.
• The current status.
• The limits of the claim.

Qualified customers may request additional documentation, in accordance with the security and compliance documentation request policy, including:

Submitting a request does not mean that all documents will automatically be provided.

Disclosure of restricted documents is subject to the Security & Compliance Documentation Request Policy.

• Security Whitepaper.
• Security Questionnaire.
• Technical & Organizational Measures.
• Incident Response Overview.
• Business Continuity Overview.
• Disaster Recovery Overview.
• Subprocessor Information.
• Data Residency Information.
• Encryption Overview.
• Access Control Overview.

Security documentation may contain sensitive information.

ZynReach therefore reserves the right to:

This is intended to prevent security information from being used in a manner that could increase risk to the platform or its customers.

• Decline the request.
• Redact portions of the document.
• Provide a summary.
• Require an NDA.
• Verify the identity of the requester.
• Restrict redistribution.

Despite taking appropriate technical and organizational measures, no information system can be absolutely immune from all risks.

Accordingly, ZynReach does not warrant that:

Any specific guarantees are subject to the applicable commercial agreements, SLA, and DPA.

• The service will be free of all vulnerabilities.
• All attacks will be prevented.
• The service will not experience any interruption.
• No security incident will occur.
• No data loss will occur under any circumstances.

This policy does not create any independent contractual liability beyond the responsibilities set forth in the applicable commercial agreement, terms of service, DPA, or SLA.

No security description in this document may be construed as:

• An absolute guarantee.
• Insurance against losses.
• A commitment to a specific security outcome.
• A waiver of any contractual right.
• An amendment to the commercial agreement.

ZynReach reserves the right to update this policy when:

The date of the last update will be indicated in the published version.

• Material changes occur in the service.
• The technical architecture changes.
• Legal requirements change.
• Security frameworks change.
• Vendor processes change.
• New risks emerge.
• Security controls are improved.

This policy is to be read together with:

In the event of a conflict, the order of priority of application shall be governed by the effective contractual agreements and applicable law.

• Terms of Service.
• Privacy Policy.
• Data Processing Agreement.
• Security & Compliance Documentation Request Policy.
• Sub-Processor Policy.
• Data Retention Policy.
• Incident Response Policy.
• Acceptable Use Policy.
• Enterprise Agreement.
• SLA, where applicable.

All content of this policy and related security documentation, including text, graphics, and methodologies, is owned by or licensed to ZynReach, and access to it does not transfer any intellectual property rights.

The website currently provides separate channels for legal and privacy matters, and also allows customers to request security and compliance documentation.

• For security inquiries — Security Team: security@zynreach.com
• For legal inquiries — Legal Team: legal@zynreach.com
• For privacy-related inquiries — Privacy Team: privacy@zynreach.com
• To request Enterprise documentation — Security & Compliance Documentation Request

If a user or customer discovers a real or potential security issue, its details must not be publicly disclosed before giving ZynReach a reasonable opportunity to investigate and address it.

Reports should be sent to: security@zynreach.com

It is preferable that the report include:

Personal data or customer data that is not necessary for the investigation should not be sent.

• A description of the issue.
• The systems affected.
• Steps to reproduce, if possible.
• The expected level of impact.
• Any necessary technical evidence.

ZynReach seeks to build a long-term relationship with its customers based on: Security. Privacy. Transparency. Accountability.

Trust is not merely a marketing phrase, but the result of practices and controls that can be reviewed and verified within the scope of the service.

This document provides a general description of ZynReach's security and trust framework, and does not constitute legal advice, an independent contractual undertaking, or an absolute guarantee of security or compliance.

This policy does not replace:

Where a specific commitment exists between ZynReach and the customer, the written and effective contractual commitment is the authoritative reference.

• Commercial agreements.
• Terms of use.
• The DPA.
• The SLA.
• The customer's specific legal requirements.

The following is the version history for this document:

• Document Name — Security & Trust Policy
• Company — Zyntra Digital / ZynReach
• Version — 1.0
• Effective Date — 31 August 2026
• Classification — Public
• Owner — Security & Compliance
• Review Cycle — At least annually
• Next Review — 31 August 2027
• Security Contact — security@zynreach.com
• Legal Contact — legal@zynreach.com
• Privacy Contact — privacy@zynreach.com
• Status — Official