Information Security Policy

At PRONETSYS S.A.S. (Pronetsys), we manage our clients’ servers, networks, websites, backups, PBX systems and applications, including those of healthcare service providers that handle sensitive data. That trust obliges us to protect our own information and that of our clients with the same care, in a systematic and verifiable way.

This policy, approved by General Management, establishes the principles, responsibilities and rules that govern information security at the company. It is aligned with the ISO/IEC 27001:2022 standard (including its Amendment 1:2024) and uses the controls of ISO/IEC 27002:2022 as guidance, without this implying certification.

1. Purpose and management commitment

General Management undertakes to:

• Protect the confidentiality, integrity and availability of the information under the company’s responsibility, with an approach based on risk management.
• Comply with the applicable legal, regulatory and contractual requirements, especially those concerning personal data protection.
• Allocate the resources, roles and competencies needed to apply this policy.
• Continuously improve controls based on incidents, audits, tests and changes in threats.

2. Information security objectives

The targets for each indicator are set by General Management based on the initial measurements, and they are monitored through the audit and monitoring process described in the Process Map.

3. Scope

This policy applies to:

• People: team members, interns, contractors and partners who access information or systems of the company or its clients, whether working remotely or during on-site visits to clients.
• Information: all company information, in any format, and the client information we manage: data hosted on our hosting, email and cloud backup services; backups we manage on client platforms; configurations, credentials and documentation of their infrastructure; and the data processed by the applications and chatbots we develop or operate.
• Technology: servers, hosting control panels, networks, work computers, mobile devices, cloud services, code repositories, the ticketing system, remote access tools and artificial intelligence tools.
• Third parties: cloud, data center, connectivity, phone trunk, licensing and other service providers that support our operations.

4. Principles

These three principles are complemented by the following:

• Least privilege and need to know: each person and system has only the permissions essential to its function.
• Defense in depth: several layers of controls, so that the failure of one does not compromise everything.
• Security and privacy by design and by default: security requirements are built in from the start of each service, project or change.
• Traceability: relevant actions are logged and can be attributed to a person.
• Demonstrated accountability: the company can provide evidence of the measures it applies to protect information.

5. Roles and responsibilities

6. Specific policies

The following specific policies develop the principles above. The associated operating procedures are found in the Process Map and in the Business Continuity Plan.

6.1 Access control and multi-factor authentication

• All accounts are individual and named; generic shared accounts are not used, except when a system allows no other option, in which case the credential is kept in the password manager and its use is logged.
• Multi-factor authentication is mandatory for email, the password manager, the VPN, hosting and cloud control panels, domain registrars, code repositories, administration consoles and the ticketing system, and it is required on client systems whenever the platform allows it.
• Accounts with administrative privileges are separate from everyday accounts and are used only for tasks that require them.
• Factory default accounts and passwords are changed or disabled before a system is put into operation.
• Access provisioning, modifications, periodic reviews and deprovisioning follow the access provisioning and deprovisioning procedure in the Process Map.

6.2 Least privilege and segregation of duties

• Permissions are granted by role, with the narrowest scope and shortest duration possible; temporary access is removed when the task is completed.
• In sensitive activities (critical changes, deletion of backups, granting of privileges), efforts are made to ensure that the person who executes is not the same person who approves.
• Access to a client’s information is limited to those who serve that client’s account.

6.3 Password manager and secrets

• All company and client credentials are stored solely in the corporate password manager, organized into vaults by client and by criticality level.
• It is prohibited to store passwords in personal browsers, notes, spreadsheets, chats or emails, and to share them through channels other than the password manager or an encrypted one-time link.
• Passwords are unique and generated by the password manager; the master password is a strong passphrase and is not reused on any other service.
• Credentials are rotated upon staff departures, suspected compromise, contract termination or use of emergency access.
• API keys, certificates and SSH keys are treated as secrets: they are not included in source code or repositories, and they are kept in the password manager or in a secrets management service.

6.4 Asset management

• An inventory of information assets is maintained: computers, servers, software and licenses, cloud services, domains, certificates, repositories and client data sets, each with an assigned owner.
• Assigned equipment is handed over and returned with a signed record. When it is no longer in use, storage media are securely wiped or destroyed before reuse, donation or disposal as waste, in coordination with the Environmental Policy.
• Only legally licensed software approved by the Technical Lead is installed.

6.5 Information classification and handling

If it has not been expressly classified, a client’s information is treated as Confidential, and information containing sensitive data, as Restricted.

6.6 Cryptography and TLS

• All web services we publish and host use HTTPS with valid certificates and automated renewal where possible, with redirection from HTTP.
• TLS 1.2 is used as a minimum, preferably TLS 1.3, and obsolete protocols and algorithms (SSL, TLS 1.0 and 1.1) are disabled.
• Laptops have full-disk encryption, and backups are encrypted in transit and at rest.
• Remote server administration is performed using encrypted protocols (for example, SSH with keys) and without direct root login by password.
• The applications we develop store user passwords using key derivation functions designed for that purpose, never in plain text or with simple hash algorithms.

6.7 Vulnerability and patch management

Keeping internet-facing components up to date is one of the most effective measures against attacks. For this reason, Pronetsys undertakes to apply security patches, including those for PHP, web servers, databases, hosting control panels, Linux operating systems, content management systems and their plugins, and network equipment firmware, within the following target timeframes, counted from when the patch becomes available or from when the vulnerability becomes known, whichever is later:

• Monitoring: the security advisories of the vendors and projects we use are monitored (including release announcements from the PHP project and from hosting control panels), and periodic vulnerability scans are performed on exposed services.
• Supported versions: on the servers we manage, only versions of PHP and other components that receive security updates are kept. Migrations are planned before the end of support of each version.
• Controlled application: patches are applied through the change management procedure, with a prior backup. Critical patches may be processed as emergency changes.
• Client systems: on client infrastructure, patches are applied according to the scope of the contract and with the client’s approval. If a client application prevents a vulnerable component from being updated, the client is informed of the risk in writing, compensating measures are proposed (isolation, web application firewall rules, access restriction) and the client’s decision is documented.
• Exceptions: any exception to these timeframes is documented with its justification, compensating measures, expiration date and approval from the Information Security Officer.
• External reports: vulnerabilities identified by third parties are received in accordance with the responsible vulnerability disclosure policy.

6.8 Information backup

Our own critical information and that of the services we provide is backed up following the 3-2-1 rule plus an immutable or offline copy, with encryption, separate credentials for backup systems and periodic restore tests. The strategy and the target RTO and RPO are set out in the Business Continuity Plan, and daily execution, verification and testing follow the backup management procedure in the Process Map.

6.9 Logging and monitoring

• Critical systems log relevant security events: successful and failed logins, use of privileges, configuration changes, access to restricted information and security errors.
• System clocks are synchronized with a reliable time source so that logs can be correlated.
• Logs are protected against modification and unauthorized access and are retained for the period defined for each type of log, according to legal and contractual requirements. As an initial target, security logs from critical systems are retained for at least six months.
• Availability and security alerts generate tickets and are reviewed as a priority.
• Corporate systems are monitored for security purposes, in a proportionate manner and respecting people’s privacy and data protection regulations.

6.10 Security in development

• The software we develop takes into account, at a minimum, the risks described in the OWASP Top 10 (2025 edition), including broken access control, security misconfiguration, software supply chain failures, injection and authentication failures.
• Security and privacy requirements are defined from the requirements-gathering stage; the personal and sensitive data that the system will process are identified.
• Code is managed with version control, peer review when possible and dependency analysis; dependencies come from trusted sources and are updated when they have known vulnerabilities.
• Development, testing and production environments are separate. Tests use fictitious or anonymized data, never real patient or user data without authorization and controls equivalent to production.
• Inputs are validated, outputs are encoded, database queries are parameterized and errors do not reveal sensitive technical information to the user.
• Deployment to production follows the project management and change management procedure in the Process Map.

6.11 Suppliers and cloud services

• Before engaging a supplier that will store or process confidential information, its security controls, data location, backup and recovery capability, and support are assessed.
• Contracts include clauses on confidentiality, security, incident notification, personal data processing, return or deletion of information upon termination and, where applicable, the conditions for the international transmission or transfer of data required by Colombian regulations.
• The shared responsibility model applies: although the provider protects its platform, the secure configuration, access and backups of what we host are our responsibility.
• Critical suppliers (cloud, data centers, connectivity, phone trunks, password manager) are reviewed at least once a year and have a documented alternative or exit plan.

6.12 Devices and remote work

• Client information is managed only on corporate computers with disk encryption, malware protection, automatic updates, screen lock and a user account without administrative privileges for daily work.
• Personal devices may be used only for corporate email and messaging, with screen lock and MFA, and never to store Confidential or Restricted information.
• When working remotely and during client visits, access to administrative systems is through a VPN or an equivalent mechanism; unprotected public networks are avoided, and care is taken that third parties do not see the screen or overhear conversations involving client information.
• Equipment is not left unattended in vehicles or public places. Its loss or theft is reported the same day to the Information Security Officer.
• Removable media are used only with encrypted information and when no safer alternative exists.
• In the remote workplace, the clean desk and clear screen policy applies: documents and equipment containing client information are not left in view or within reach of third parties, and the router of the connection used for work is protected with a strong password and up-to-date firmware. Our own infrastructure is hosted in data centers and with cloud providers that have restricted physical access, and at client premises their access controls for areas with network equipment or servers are respected.

6.13 Acceptable use

• The company’s technology resources are used for work purposes; occasional personal use is allowed as long as it does not create risks, costs or conflicts with this policy.
• The following are prohibited: installing unlicensed or unapproved software; disabling or circumventing security controls; sharing credentials; accessing systems or information without authorization, including those of clients outside the authorized scope; downloading or distributing illegal or offensive content; and using client information for purposes other than the contracted service.
• Remote access to client equipment is performed only with the client’s authorization, using approved tools and recording it in the ticket.

6.14 Generative artificial intelligence and client data

• Only AI tools approved by the company are used, whose contractual and technical terms offer confidentiality guarantees and exclude the use of the information entered to train models. Using personal accounts on AI tools with company or client information is prohibited.
• Personal data of clients or their users, sensitive data, credentials, infrastructure configurations, and confidential code or documents are not entered into AI tools, unless the tool is approved for that classification level and the client has authorized it.
• All AI-generated output (code, text, configurations, analyses) is reviewed by a competent person before it is used; generated code undergoes the same review and the same security testing as manually written code, and it is verified that it does not infringe third-party licenses.
• The chatbots we develop or operate for clients apply data minimization; inform users that they are interacting with an automated system; offer the option to be transferred to a human agent; avoid requesting unnecessary sensitive data; define how long conversations are retained; and include protections against the manipulation of their instructions (prompt injection).
• The processing of personal data in AI systems follows the guidelines of the Superintendence of Industry and Commerce set out in its External Circular 002 of 2024.

6.15 Incident management and notification

A security incident is any event that compromises or may compromise the confidentiality, integrity or availability of information, such as unauthorized access, a malware infection, the loss of a device or sending information to the wrong recipient. Every team member must immediately report any incident or suspicion to the Information Security Officer. Third parties may report to soporte@pronetsys.com.co.

1. Report and registration. The incident is recorded with the time of detection, who reported it, the systems involved and the initial observations.
2. Assessment and classification. The Information Security Officer determines its severity, whether it involves personal or sensitive data and which clients could be affected. If the impact warrants it, the Business Continuity Plan is activated.
3. Containment. The damage is limited: isolating devices, locking accounts, revoking sessions, rotating credentials or blocking access.
4. Investigation and evidence. The cause, scope and timeline are determined, preserving the logs and evidence needed for any legal action.
5. Eradication and recovery. The cause is eliminated, vulnerabilities are corrected and services are restored from trusted sources, verifying their integrity.
6. Notification to clients. When an incident affects a client’s information or services, the client is informed without undue delay, with the goal of providing an initial notice within 24 hours after the incident is confirmed, or within the shorter period established in their contract. The notice includes what is known, the affected data and services, the measures taken and those recommended. When we act as a processor, this notice enables the client to fulfill its own obligations as the data controller.
7. Notification to the Superintendence of Industry and Commerce. Law 1581 of 2012 requires controllers (Article 17, item n) and processors (Article 18, item k) to inform the data protection authority when there are violations of security codes and risks in the management of data subjects’ information. When Pronetsys acts as the controller, it will report the incident to the SIC through the National Database Registry within fifteen (15) business days after its detection, as provided by the SIC in its Single Circular (Circular Única). When it acts as the processor, it will coordinate the notification with the client acting as controller and will fulfill its own duty to inform the SIC. These notifications are managed together with the Personal Data Protection Officer.
8. Communication to data subjects. When the incident poses a risk to the data subjects, communication to those affected is coordinated with the data controller, with recommendations on how to protect themselves.
9. Report to the authorities. When the facts may constitute computer crimes under Law 1273 of 2009, General Management, with legal advice, evaluates filing a criminal complaint with the Attorney General’s Office (Fiscalía General de la Nación) or the National Police.
10. Closure and lessons learned. The root cause, impact, corrective actions and improvements are documented and managed through the continuous improvement process.

6.16 Awareness and training

• Every new team member receives onboarding on information security, personal data protection and responsible use of AI before accessing client information.
• Staff receive refresher training at least once a year and take part in phishing email simulations.
• Service desk technicians receive specific training in identity verification and social engineering prevention; developers, in secure development.
• Timely alerts are shared about threats relevant to our clients and our operations.

7. Legal and contractual compliance

The company identifies and complies with the applicable legal, regulatory and contractual requirements. The main ones include:

Contractual obligations with each client (confidentiality agreements, data processing agreements and SLAs) complement this policy and prevail when they are more demanding.

8. Non-compliance and sanctions

Non-compliance with this policy can put our clients and the company at risk. Therefore:

• For team members, non-compliance is treated as a disciplinary offense, with respect for due process and in accordance with the Internal Work Regulations, the contract and labor law. The measure is proportionate to the severity, intent and impact.
• For contractors and suppliers, it may give rise to the consequences provided for in the contract, including its termination.
• The foregoing does not exclude any applicable civil or criminal actions.
• Reporting one’s own error or an incident in good faith is not sanctioned for the act of reporting it; concealing it does constitute non-compliance.

Non-compliance may also be reported confidentially through the Ethics Hotline, in accordance with the Code of Ethics and Conduct.

9. Review and update

This policy is reviewed by the Information Security Officer and approved by General Management at least once a year, and also whenever significant incidents occur, there are relevant changes in services, technology or threats, or there are legal and contractual changes. Previous versions are kept as a record.