Process and Procedure Map

This document presents the process map of PRONETSYS S.A.S. (Pronetsys), NIT 901.386.859-4, and describes how work is organized to turn our customers’ needs into reliable technology solutions: from the first sales conversation to technical support, the operation of managed services and continuous improvement.

The map follows the process approach and the Plan–Do–Check–Act cycle promoted by the ISO 9001 standard (2026 edition). It is an internal management tool that we share for transparency; it does not constitute a statement of certification. It is complemented by the Business Continuity Plan, the Information Security Policy and the Environmental Policy.

1. Objective and scope

The objective of the process map is to provide a comprehensive, shared view of how Pronetsys operates, so that every staff member, customer and partner understands what we do, who is responsible for each stage, how the areas relate to one another and how we measure performance. Specifically, it seeks to:

• Identify the processes needed to provide our services with quality, security and continuity.
• Define for each process its objective, owner, inputs, activities, outputs and indicators.
• Make the interactions between processes visible to avoid gaps in responsibility and rework.
• Establish step-by-step key procedures for the activities with the greatest impact on the customer and on the security of their information.
• Serve as the basis for measurement, internal audit and continuous improvement.

The scope covers all the services in the portfolio: IT consulting; Level 1 to Level 3 (L1 to L3) technical support on a per-incident basis and through ticket bundles; sale of hardware and software; web and mobile development; AI-powered chatbots; web design; hosting and domains; cloud backup (on our own infrastructure and managed on customer platforms); virtual VoIP telephony; network design and implementation (structured cabling and Wi-Fi); digital signage; streaming; data analytics and business intelligence; and ERP and CRM consulting. It applies to work performed remotely—the company has no physical office and serves its customers through virtual channels—and to technical visits to customers in Medellín, Antioquia, Colombia and the Aburrá Valley (Medellín metropolitan area).

2. Process map

The map reads from left to right: the needs and expectations of customers and interested parties enter the value chain and are transformed, through the core processes, into satisfied customers and continuous technology operations. The strategic processes provide direction; the support processes provide resources; and the evaluation and improvement processes verify and provide feedback to all the others.

3. Reference roles

The following roles are used in the process descriptions and procedures in this document and in the other corporate governance documents. They are assigned by name by General Management.

General Management

Senior management. Sets the direction, approves policies, resources and accepted risks, and leads the management review.

Sales Lead

Manages opportunities, quotations, contracts and the business relationship with customers.

Technical Lead

Is accountable for our own infrastructure and the customer infrastructure under management, technical changes and the operation of managed services.

Projects and Development Lead

Plans and controls software, chatbot, analytics and integration projects, and their technical quality.

Service Desk Coordinator

Manages the receipt, classification, escalation and closure of tickets, and compliance with service level agreements (SLAs).

Information Security Officer

Coordinates the management of security risks, controls, incidents and awareness, in accordance with the Information Security Policy.

Continuity Lead

Maintains and tests the Business Continuity Plan and coordinates its activation.

Administrative and Financial Officer

Manages invoicing, accounts receivable, payments, budget and administrative support for purchasing and contracts.

Human Resources Officer

Manages recruitment, hiring, onboarding, training, wellbeing and separation of personnel.

Environmental Management and OHS Officer

Coordinates the environmental and occupational health and safety (OHS) programs.

Quality and Improvement Officer

Maintains this process map, consolidates indicators, coordinates internal audits and follows up on improvement actions.

4. Description of strategic processes

The strategic processes set the company’s direction, manage the risks that could prevent it from meeting its commitments to customers and renew the portfolio to respond to technological change.

4.1 E1 Strategic direction

4.2 E2 Risk and compliance management

4.3 E3 Innovation and portfolio

5. Description of core processes

The core processes make up the value chain: each one delivers a verifiable result to the next, and the customer participates at the decision points (acceptance of the proposal, validation of deliverables, approval of changes and confirmation of ticket closure).

5.1 M1 Sales management

5.2 M2 Solution design

5.3 M3 Implementation and delivery

5.4 M4 Managed services operation

5.5 M5 Technical support and service desk

6. Description of support processes

The support processes provide the people, equipment, suppliers, information and financial resources that the value chain needs, under criteria of security, legality and sustainability.

6.1 A1 Human resources

This process is aligned with the Code of Ethics and Conduct, the Wellbeing and Workload Policy, the Workplace Conduct Handbook and the harassment prevention policy.

6.2 A2 Purchasing, suppliers and warranties

6.3 A3 Internal infrastructure and assets

6.4 A4 Administrative and financial management

6.5 A5 Document and knowledge management

6.6 A6 Environmental and OHS management

The detailed guidelines are set out in the Environmental Policy and in the Occupational Health and Safety Policy.

7. Description of evaluation and improvement processes

These processes verify that the others fulfill their purpose and turn findings, complaints and incidents into concrete improvements.

7.1 V1 Customer satisfaction and experience

7.2 V2 Audit and monitoring

7.3 V3 Continuous improvement

8. Interaction between processes

No process works in isolation. The following table summarizes the main interactions: what each process delivers and who receives it. Requests and records are channeled, whenever possible, through the ticketing system, to maintain traceability.

The improvement cycle closes in the management review (E1): there, the indicators, customer satisfaction, incidents, the results of continuity tests and environmental performance are analyzed, and adjustments to the objectives, the resources and this map itself are decided.

9. Key procedures

The following procedures describe, step by step, the activities with the greatest impact on customers and on the security of their information. Each procedure leaves records in the ticketing system or in the customer’s or project’s file. The response and resolution times committed to each customer are those agreed in their contract and in the Support Service Terms.

9.1 Management of support incidents and requests (tickets)

Applies to all incidents, requests and inquiries received by the service desk, under both the per-incident modality and ticket bundles. Tickets are handled during the hours established in the Support Service Terms (8:00 a.m. to 4:00 p.m. time slot); cases received outside those hours are logged and handled at the start of the next business period, unless extended-hours support has been agreed with the customer.

Support levels

Priorities

Steps

1. Receipt and logging. Every case received through the support portal, WhatsApp (chatbot), phone or email is logged in the ticketing system with a unique number, the requester’s details, a description and evidence. No work is performed without a ticket, to ensure traceability and control of bundle consumption.
2. Validation of the requester and the contract. It is verified that the requester is an authorized contact of the customer and that there is a contract, a bundle with a balance or an acceptance of per-incident service. Password reset requests or requests for new access require additional identity verification, to prevent impersonation (social engineering).
3. Classification and prioritization. The type (incident, request, inquiry or possible security incident), the category and the priority are defined according to impact and urgency. A possible security incident is also handled under the procedure of the Information Security Policy.
4. L1 support. The service desk attempts to resolve the case on first contact using the knowledge base. Remote access to the customer’s equipment is performed only with their express authorization and with approved tools, and each action is documented in the ticket.
5. Functional escalation to L2 and L3. If the case exceeds the scope or the internal time defined for L1, or requires a visit, specialized knowledge or the intervention of a manufacturer, it is escalated with a summary of the diagnosis and what has already been tried, so that the customer does not have to repeat the information.
6. Hierarchical escalation. P1 cases, cases at risk of breaching the SLA and cases from dissatisfied customers are reported to the Service Desk Coordinator and, if necessary, to the Technical Lead and Management, who assign additional resources.
7. Diagnosis and resolution. If the resolution requires modifying the customer’s infrastructure, the change management procedure (9.2) is applied; if it is a failure covered by warranty, the purchasing and warranties procedure (9.5) is applied. On-site visits are grouped by area when the priority allows it.
8. Communication and follow-up. The customer receives updates in the ticket upon relevant status changes (assigned, awaiting information, awaiting third party, resolved). Time spent awaiting information from the customer or third parties is recorded.
9. Confirmation and closure. The cause and the resolution are documented, the time and the bundle consumption are recorded, and the customer is asked to confirm the resolution. If the customer does not respond within the confirmation period that the service desk communicates in the ticket, the ticket is closed with an explanatory note and may be reopened if the problem persists.
10. Satisfaction survey. A brief survey is sent upon closure. Low ratings trigger contact with the customer by the Service Desk Coordinator and, where appropriate, an improvement action.
11. Recurrence analysis. Repeated or high-impact incidents are recorded as problems, their root cause is analyzed and the solution is documented in the knowledge base.

9.2 Management of changes to customer infrastructure

Applies to any modification of customers’ servers, networks, firewalls, hosting control panels, DNS, VoIP telephony, databases, applications in production and cloud services, as well as of our own infrastructure that supports customer services. Three types of change are distinguished: standard (low-risk, repetitive and with a documented procedure, pre-approved), normal (requires assessment and approval) and emergency (necessary to restore a service or mitigate a critical vulnerability; it is approved on an expedited basis and fully documented afterwards).

1. Change request. It is logged in the ticketing system with the description, the justification, the affected systems and the requester. Changes requested by the customer must come from an authorized contact.
2. Impact and risk assessment. The technical owner analyzes the affected services and users, dependencies, impact on security and on personal data, expected downtime and risks of failure.
3. Implementation and rollback plan. The steps, the verification tests and the rollback plan, with its activation criterion, are documented. A normal change is not approved without a rollback plan.
4. Approval. The Technical Lead approves internally and the customer approves in writing (in the ticket or by email) when the change affects their infrastructure or their service. In small teams, approval is given by a person other than the one who executes the change, whenever possible.
5. Scheduling and communication. A maintenance window is agreed that minimizes the impact on the customer’s operations (for example, outside patient care hours in the case of healthcare providers [IPS]) and the affected users are notified.
6. Prior backup. Before execution, a backup or snapshot of the systems and configurations to be modified is taken and verified.
7. Execution. The change is executed according to the plan, recording the start time, actions, deviations and end time.
8. Post-implementation verification. The defined functional tests are run and monitoring is reviewed. The customer validates that their operations are working correctly.
9. Rollback, if applicable. If the rollback criterion is met, the previous state is restored, the customer is informed and the change is rescheduled after analyzing the cause.
10. Closure and documentation. The inventory, the diagrams, the customer’s technical documentation and, if credentials changed, the password manager are updated. Emergency and failed changes are reviewed in the continuous improvement process.

9.3 Management of development projects

Applies to web and mobile development, web design, AI-powered chatbot, analytics and ERP or CRM integration projects. Secure development practices are detailed in the Information Security Policy.

1. Initiation. Once the proposal or contract has been approved, the project kickoff record is prepared: objective, scope, deliverables, roles of both parties, communication channels and general acceptance criteria.
2. Requirements gathering. Functional and non-functional requirements (performance, availability, accessibility, security) are documented, and it is determined whether the system will process personal or sensitive data, in order to apply privacy by design and agree on each party’s role with respect to that data.
3. Planning. The milestone-based schedule, the effort estimate, the project risks, the environments (development, testing and production) and the testing strategy are defined.
4. Design. The architecture, the data model, the user experience and the security controls (authentication, authorization, input validation, event logging) are designed. For AI solutions, the model or service used, the data it will process and the safeguards against incorrect responses are documented.
5. Iterative development. The code is managed in repositories with version control and backup, using branches and peer code review whenever possible. Credentials and keys are never stored in the code, and dependencies are taken from trusted sources and kept up to date.
6. Testing. Functional, integration, security (including the OWASP Top 10 categories) and compatibility tests are run. Tests use fictitious or anonymized data; never real patient or user data without authorization and controls equivalent to production.
7. Scope change control. Any request that modifies the scope is assessed in terms of time, cost and risk, and is executed only with the customer’s written approval.
8. Customer validation. The customer performs acceptance testing in the test environment and signs the acceptance record or reports observations, which are corrected and validated again.
9. Deployment to production. Deployment to production follows the change management procedure (9.2), with a prior backup and a rollback plan.
10. Delivery and closure. The technical and user documentation, the code or the access according to the contract, and the credentials through a secure channel are delivered. The agreed training is provided and the closure record is signed, which marks the start of the warranty or support period.
11. Lessons learned. The team records what worked, what did not and what to change in future projects; improvements are referred to the continuous improvement process.

9.4 Sales and quotation

1. Recording the opportunity. Every sales request received through the website (https://pronetsys.com.co), WhatsApp, phone, email (contactenos@pronetsys.com.co) or referrals is recorded with the contact details, the need and the date of receipt.
2. Qualification and assessment. The actual need, the scope, the budget, the urgency and the customer’s context are clarified (for example, whether they handle sensitive health data or require special availability).
3. Definition of the solution. The Sales Lead consults the technical area to confirm feasibility, available capacity and, in the case of hardware, compatibility, availability, the manufacturer’s warranty and energy efficiency criteria.
4. Preparation of the quotation. The quotation states the scope, exclusions, deliverables, timeframes, prices and taxes, payment terms, warranty (in accordance with the Warranty Policy), SLAs where applicable and the validity period of the offer.
5. Internal review and approval. Before sending, margins, execution capacity and risks are verified. Offers that exceed the thresholds defined by General Management require its approval.
6. Sending and follow-up. The quotation is sent through a formal channel and followed up during its validity period. Each adjustment generates a new version, to avoid confusion about the terms in force.
7. Formalization. The sale is formalized with written acceptance, a purchase order or a contract. When Pronetsys will process personal data on behalf of the customer, the corresponding data transmission or processing agreement is also signed, in line with the Personal Data Processing Policy.
8. Handover to operations. The Sales Lead delivers a handover sheet to the design, purchasing, support and invoicing processes with everything that was agreed, so that nothing depends on one person’s memory.
9. Recording the outcome. Whether the opportunity was won or lost, and the reason, is recorded as input to improve the portfolio and the value proposition.

9.5 Hardware purchasing and warranties

Purchasing

1. Identification of the need. The need arises from a formalized sale or from an approved internal requirement.
2. Technical specification. The Technical Lead defines the specifications, including compatibility, the manufacturer’s warranty, energy efficiency, repairability and security requirements (for example, support for firmware updates).
3. Supplier selection. Purchases are preferably made through channels authorized by the manufacturer, to ensure the warranty and the legitimacy of licenses. Where applicable, quotations from evaluated suppliers are compared.
4. Purchase order. The approved order is issued according to the authorization levels in force.
5. Receipt and inspection. Quantity, model, physical condition, seals and documentation are verified, and the serial numbers and the warranty start date are recorded. Nonconformities are reported to the supplier immediately.
6. Preparation. Before delivery, the firmware and operating system are updated, licenses are activated and the agreed secure configuration is applied.
7. Delivery and installation. The equipment is delivered to the customer with a signed record that registers the serial numbers, warranty terms and condition of the equipment.
8. Packaging. Packaging is separated for recovery or returned to the supplier when that option exists, in accordance with the Environmental Policy.

Warranties

1. Receipt of the claim. The customer reports the failure through a ticket, with the invoice or the delivery record when they have it at hand.
2. Technical diagnosis. The failure is verified and external or usage-related causes are ruled out. If the equipment contains information, a prior backup of the customer’s data is agreed with them.
3. Coverage verification. The serial number, validity and terms of the manufacturer’s or supplier’s warranty are confirmed.
4. Information protection. Before sending a device or a disk to the manufacturer, secure erasure or retention of the storage medium is agreed with the customer, especially when it contains sensitive data.
5. Processing with the manufacturer or wholesaler. The return merchandise authorization (RMA) is managed and the case number and dates are recorded.
6. Follow-up and customer updates. The customer receives information on the status of the claim and, if their contract provides for it, a loaner device while the repair is under way.
7. Delivery and closure. The repaired or replaced equipment is delivered with a signed record, the ticket is closed, and any replaced parts that remain in the company’s possession are managed as waste electrical and electronic equipment (WEEE).

9.6 Backup management

Applies to backups of Pronetsys’s own infrastructure (including the hosting and cloud backup services it provides to customers) and to the backups it manages on customer platforms. For the latter, the contract defines the shared responsibility: who provides the platform, the storage and the licenses, and the scope of the verification performed by Pronetsys. The backup strategy follows the 3-2-1 rule with an additional immutable or offline copy, as described in the Business Continuity Plan.

1. Backup catalog. A catalog is maintained that indicates, for each system or customer: what is backed up, frequency, retention, location of each copy, encryption, owner and target RPO. Every addition or removal of a service updates the catalog.
2. Daily execution. Backups run automatically according to the catalog, preferably outside peak usage hours, and are encrypted in transit and at rest.
3. Daily review of results. Every business day, the success or failure reports and alerts are reviewed, as well as abnormal variations in size or in the number of modified files, which may indicate malicious encryption (ransomware).
4. Handling of failures. Every failed backup generates a ticket, is rerun and its cause is analyzed. If a failure affects a backup service contracted by a customer and is not corrected within the timeframe set out in their contract, the customer is informed.
5. Replication and protected copy. It is verified that the copies are replicated to the secondary location and that the immutable or offline copy has been generated according to its schedule.
6. Integrity verification. At least weekly, the integrity of the copies is verified (checksums, readable catalogs and complete backup chains).
7. Sample restore test. At least monthly, selected files, mailboxes or databases are restored in an isolated environment and it is confirmed that the information is complete and usable.
8. Full restore test. At least quarterly, a critical service (for example, a hosted website with its database, or a server) is fully restored, the time taken is measured and compared with the target RTO.
9. Recording of evidence. Each test leaves a record of the date, scope, result, time and owner; deviations generate improvement actions.
10. Retention and deletion. When the retention period expires or a contract ends, the copies are securely deleted or delivered to the customer as agreed, and a record is kept.

9.7 Access provisioning, modification and deprovisioning

Applies to the accounts of staff members and contractors on our own systems, and to the credentials for customer systems that Pronetsys holds in custody to provide its services. The authentication and password manager rules are established in the Information Security Policy.

Staff onboarding

1. Formal request. Human Resources requests the creation of access, indicating the role, the start date and the type of employment relationship.
2. Prior agreements. The person signs their contract with confidentiality clauses and accepts the security, acceptable use and data processing policies before receiving access.
3. Role-based profile. Permissions are assigned according to the role profile and the principle of least privilege; privileged access requires approval from the Technical Lead.
4. Account creation. Named accounts (never shared) are created, with multi-factor authentication enabled from day one.
5. Equipment and password manager. An inventoried, encrypted and up-to-date device is provided, along with access to the password manager limited to the vaults the role requires.
6. Security onboarding. Onboarding in information security, data protection and the use of AI tools is provided.
7. Recording. The access granted is recorded in the access matrix.

Modification and periodic review

1. Role change. When duties change, the new access is granted and access that is no longer required is removed, in the same request.
2. Periodic review. Leads review the access matrix at least every six months, and privileged and customer access at least quarterly. Unused or unjustified accounts are disabled.

Staff offboarding

1. Notification. Human Resources reports the effective separation date as far in advance as possible; for unscheduled separations, notification is immediate.
2. Account deactivation. Accounts are disabled no later than the end of the last working day, or immediately in unscheduled separations, including active sessions, VPN, MFA factors, SSH keys and API tokens.
3. Credential rotation. Based on the password manager’s usage log, the shared and customer credentials to which the person had access are rotated, prioritizing the most critical ones.
4. Return of assets. Equipment, media and authentication devices are received with a signed record; equipment is backed up, if applicable, and securely wiped before being reassigned.
5. Knowledge transfer. Ownership of files, mailboxes and open tickets is transferred, and any pending knowledge is documented.
6. Closure. The person is reminded in writing that their confidentiality obligations remain in force, and the separation checklist is signed.

Customer credentials

1. Receipt through a secure channel. Credentials are received through the password manager or a single-use encrypted link; never in plain text via chat, WhatsApp or unencrypted email. If the customer sends them through an insecure channel, they are advised to change them.
2. Custody. They are stored only in the password manager, in a vault for each customer with access restricted to those who service that account.
3. Named accounts. Whenever the customer’s platform allows it, named accounts with MFA are requested for each technician, instead of generic shared accounts.
4. Rotation. Credentials are rotated upon staff departures, suspected compromise, relevant changes or when the customer requests it.
5. Termination of service. When the contract ends, the administrative credentials are formally handed over to the customer, who is advised to rotate them; the copies held by Pronetsys are deleted, and a signed record is kept.

10. Measurement, review and updating

The indicators suggested in each process description are a starting point. Each process lead defines with General Management the formula, data source, measurement frequency and target for each indicator once sufficient historical data is available to establish a baseline. The results are consolidated in the audit and monitoring process and analyzed in the management review.

This process map is reviewed at least once a year and whenever there are significant changes in the service portfolio, the team structure, the legal requirements or the results of audits and incidents. Improvement suggestions can be sent to contactenos@pronetsys.com.co.