Information Security & Data Handling Policy

Last review: 2025-12-1

Version: 1.0

Owner / Responsible: Guadalsistema SL

1. Purpose

The purpose of this policy is to define how we handle, protect and process information and data — whether our own, our clients’, or data intermediated via our services — in order to preserve confidentiality, integrity, and availability, to avoid unauthorized access, leaks or loss, and to ensure trust from our clients and partners. This policy establishes minimum security rules, operational best-practices, and responsibilities for data management within the organization.

2. Scope

This policy applies to all systems, servers, services, processes and data operated by the organization. It includes:

• Virtual servers or any IT infrastructure managed by us.
• Data transfers between clients’ ERP, our proxy, third-party services (e.g. external APIs), and back.
• Logs, records, configurations, and any data stored — whether temporarily or persistently.
• Any person or role that accesses, processes or manages those systems or data (in this case: the administrator / developer responsible).

Public or already public data (public web content, anonymized data, etc.) are excluded from the scope of this policy.

3. Security Principles

The organization commits to the following security principles:

• Confidentiality — data must only be accessed by authorized personnel.
• Integrity — data must not be altered, corrupted or tampered with without authorization; processing must respect data integrity.
• Availability — authorized users must have access to required data and services when needed.
• Principle of Least Privilege — each user/role only receives the minimal permissions strictly necessary.
• Transparency & Accountability — data flows, access, storage and processing must be documented and auditable.
• Protection of Sensitive Data — personal or sensitive data must be treated with heightened security measures (encryption, restricted access, minimized retention).

4. Data Classification and Handling

4.1 Data Classification

We categorize data handled by our systems into at least the following sensitivity levels:

Before storing or transmitting any data, we classify it according to this scheme.

4.2 Data Handling Rules

• Data classified as “Confidential” or “Restricted” must be handled with appropriate security safeguards: encrypted during transit (e.g. via TLS/HTTPS), access restricted to authorized roles only, and logging of access.
• If any sensitive data is stored on disk, encryption at rest should be used when feasible.
• Operational logs or internal metadata should be stored in secure partitions, with filesystem permissions restricting access, and not exposed publicly.
• Data retention should be limited to what is strictly necessary; unnecessary or obsolete data should be removed securely once retention period or purpose ends.

5. Access Control and Authentication

• Only the assigned administrator (or responsible developer) has direct access to the server(s) and infrastructure.
• Access uses secure authentication methods (e.g. SSH keys, strong passwords). If possible, multi-factor authentication (MFA) should be enabled.
• The principle of least privilege is enforced: no unnecessary permissions, no shared generic credentials.
• All authorized accesses are logged. No credentials are shared casually.

6. Secure Configuration and Operational Hygiene

• Servers and software must be kept up-to-date with security patches on a regular basis.
• When possible, systems should be configured following “hardening” guidelines: unused ports closed, unnecessary services disabled, firewall rules or network controls applied.
• Any endpoints (if applicable) should have protection (e.g. antivirus or malware protection), and security updates applied.
• Dependencies, libraries or external tools must be maintained and updated to avoid security vulnerabilities.

7. Data Transfer & Third-Party Communication

• All data transfers to external services (e.g. APIs, external platforms) must happen over encrypted channels (TLS/HTTPS).
• Only the minimum required data should be shared with third parties.
• Data transfer must be documented: what data, purpose, recipient, and legal/compliance basis (if applicable).

8. Logging, Monitoring & Audit

• Access logs, data-exchange logs, and critical event logs should be maintained to allow traceability and auditing.
• Logs must be stored securely, with restricted access.
• A retention period for logs should be defined; after that period, logs should be securely deleted or archived.
• Logs or system activity should be reviewed periodically to detect anomalies or unauthorized activity.

9. Incident Response & Vulnerability Management

Even though our organization is small, we commit to a basic incident response and vulnerability management process:

• In case of a security incident (unauthorized access, data leak, malware, server compromise, etc.), the responsible person must:
  1. Contain the incident (isolate affected systems, disable access if needed).
  2. Assess the scope and impact (which data or systems affected).
  3. Notify affected parties (clients, partners) if relevant.
  4. Restore services from secure, clean backup if needed.
  5. Document the incident: date, cause, impact, resolution steps, lessons learned.
  6. Review policies and improve controls to prevent recurrence.
• Periodically (e.g. monthly or quarterly) review system for vulnerabilities: check for required patches, outdated dependencies, insecure configurations.

10. Roles & Responsibilities

• Policy Owner (Organization / Company): ensures this policy is reviewed and kept up-to-date; approves any major change; defines overall security strategy.
• Administrator / Data Custodian: implements technical controls; maintains secure configuration; handles backups, logging, monitoring; executes incident response when required.
• Clients / Users (when applicable): do not have direct access to internal infrastructure; if any data is shared, they must abide by the handling rules defined here.

11. Review & Update

• This policy should be reviewed at least once per year — or sooner if there are significant changes in infrastructure, data handling practices, regulatory requirements or identified risks.
• Each update must be versioned, with date, author, and brief description of changes.

12. Public Disclosure & Transparency

We commit to publishing this policy (or a summary thereof) in a publicly accessible place (e.g. website), so clients, partners, or external reviewers can understand how we manage data and security — even if our team is small. Transparency helps build trust and demonstrates our commitment to data protection.