Version: 1.0  Effective Date: November 2025
Applies To: iWoWSoft HRMS — SaaS, IaaS and On-Premises Deployments

---

1. Purpose and Scope

This Incident Response Plan (IRP) describes how iWoWSoft handles security incidents related to the iWoWSoft HRMS platform, including:

• Cyber attacks (e.g. hacking attempts, malware, ransomware)
• Unauthorised access to systems or accounts
• Suspected or confirmed personal data breaches
• Other events that may affect the confidentiality, integrity or availability of customer data

The plan applies to:

• The HRMS production environment hosted in IPServerOne’s CJ1 data centre (Cyberjaya, Malaysia)
• Supporting systems used to operate the HRMS (monitoring, logging, ticketing, email)
• iWoWSoft staff who administer or support the HRMS

This is a customer-facing summary. Detailed internal procedures and technical runbooks are maintained by iWoWSoft and are not published for security reasons.

2. Definitions

• Security Incident
  Any event that may compromise the confidentiality, integrity or availability of the HRMS or its data. This includes attempted or suspected incidents, not only confirmed breaches.
• Personal Data Breach (PDPA)
  Any event that leads to, or is likely to lead to, the loss, misuse, unauthorised access or disclosure of personal data, whether accidental or deliberate, internal or external.
• Significant Harm (PDPA Amendment 2024)
  A personal data breach that may result in physical harm, financial loss, damage to credit, property loss, illegal misuse, or similar serious consequences, and therefore triggers mandatory notification to the Personal Data Protection Commissioner and affected data subjects, in line with applicable guidelines and timelines.

3. Roles and Responsibilities

iWoWSoft does not maintain a full-time “incident manager” position.
Instead, for each significant incident, specific roles are appointed from existing team members.

• Incident Coordinator (IC) – appointed per incident
  • Overall coordinator during the incident
  • Works closely with technical team members and the Support Lead
  • Decides on severity level and escalation
  • Recommends, together with management, whether to invoke Disaster Recovery (DR) actions
  • Approves customer communications from the technical side
• Technical Team Members
  • Perform technical investigation, forensics and remediation under the guidance of the Incident Coordinator
  • Provide updates on root cause, impact and required fixes
• Support Lead (SL)
  • Manages customer-facing communication via ticketing and email
  • Coordinates with the Incident Coordinator and technical team to ensure consistent, accurate updates to affected customers
• Data Protection Lead (DPL)
  • Acts as the focal point for personal data breach assessment
  • Coordinates with management on whether a PDPA data breach notification is required
  • Oversees notifications to the PDP Commissioner and affected data subjects when required
• Management / Executive Sponsor
  • Provides decision-making support for high-impact incidents
  • Approves high-level statements to customers, regulators or partners

The same person may hold more than one role in smaller incidents (for example, a senior technical person may act as both Incident Coordinator and Technical Lead).

4. Incident Severity Levels

Incidents are classified into four levels to prioritise response:

• SEV1 – Critical
  • Confirmed or strongly suspected data breach affecting multiple customers or sensitive data
  • Major service disruption or compromise of core HRMS systems
  • Likely to trigger regulatory or contractual notification
• SEV2 – High
  • Serious security issue affecting one customer or a limited subset of data
  • Significant but not total impact on availability, integrity or confidentiality
  • Requires urgent response but may not meet “significant harm” threshold
• SEV3 – Medium
  • Isolated security event (e.g. suspicious login, minor misconfiguration)
  • No evidence of data exfiltration or major disruption
• SEV4 – Low / Informational
  • Benign alerts, blocked scans, or policy violations without real impact
  • Logged for monitoring and trend analysis

Severity can be upgraded or downgraded as more information becomes available.

5. Incident Response Lifecycle

iWoWSoft follows a standard incident response lifecycle:
Preparation → Detection & Reporting → Triage & Classification → Containment → Investigation → Eradication & Recovery → Communication → Post-Incident Review.

5.1 Preparation

• Maintain up-to-date system and network documentation
• Implement security controls (firewalls, access control, backups, logging, malware protection)
• Define roles, severity levels and communication channels
• Train relevant staff on how to recognise and report incidents

5.2 Detection & Reporting

Incidents may be detected via:

• Monitoring and alerting (system logs, security alerts)
• Reports from customers (support tickets or email)
• Internal staff noticing unusual activity

When a potential incident is detected:

1. A ticket is created in the support/incident system.
2. A suitable person is appointed as Incident Coordinator for that incident.
3. Initial information is recorded:
   • Time and source of report
   • Systems involved
   • Symptoms (unusual activity, alerts, errors)
   • Any immediate impact observed

5.3 Initial Triage & Classification

The Incident Coordinator, with the technical team:

• Confirms whether the event is a security incident or a false alarm.
• Assigns a severity level (SEV1–SEV4).
• Decides whether to involve the Data Protection Lead (for suspected personal data breaches).

For suspected personal data breaches, the incident is immediately escalated to at least SEV2 pending further analysis.

5.4 Containment

Containment aims to limit damage quickly while preserving evidence where possible.

Possible actions:

• Disable or reset compromised user accounts
• Revoke or rotate exposed credentials (API keys, passwords, certificates)
• Isolate affected servers or services from the network
• Temporarily disable risky features or integrations

Decisions are taken to balance:

• Stopping further harm; and
• Avoiding unnecessary downtime or data loss.

5.5 Investigation & Analysis

Under the coordination of the Incident Coordinator, technical team members:

• Identify root cause (e.g. misconfiguration, vulnerability, compromised credential)
• Determine scope:
  • Systems and components affected
  • Time window
  • Data or customers potentially impacted
• Assess whether there has been:
  • Unauthorised access, modification or exfiltration of data
  • Damage to the integrity of stored data

For suspected personal data breaches, the Data Protection Lead assesses:

• Whether the incident meets the definition of a personal data breach; and
• Whether it may cause significant harm to data subjects, triggering PDPA notification obligations.

5.6 Eradication & Recovery

Once the incident is understood and contained:

• Remove malicious code, close backdoors, revoke compromised accounts and keys
• Apply patches, configuration changes or additional security rules
• If required, restore affected systems or data from backups in line with our BC/DR plan:
  • Where data remains intact (e.g. hardware failure, network outage), recovery is usually achieved without backup restore, so there is no data loss.
  • Where data is corrupted or destroyed, we restore from the most recent clean backup, accepting the normal RPO (typically up to one day; up to seven days only in the extreme offline-restore scenario described in our BC/DR Plan).

Before closing the recovery phase:

• Perform functional and basic security checks on the restored systems
• Confirm that services are stable and no further malicious activity is observed

5.7 Communication & Notification

Communication is coordinated between the Incident Coordinator and Support Lead:

1. Internal communication
   • Regular updates inside the incident ticket and internal channels
   • Clear record of decisions, actions and timings
2. Customer communication
   • For customer-impacting incidents, the Support Lead informs affected customers via email and ticketing system.
   • Messages include:
     • What is known at that time
     • Impact on availability and/or data
     • Actions being taken and next steps
3. Regulatory / PDPA notification
   • For confirmed personal data breaches that may cause significant harm, iWoWSoft will:
     • Notify the Personal Data Protection Commissioner (PDP Commissioner) as soon as practicable and within the required timeframe under applicable guidelines.
     • Notify affected data subjects where required, with:
       • A description of the incident and data involved
       • Potential risks to them
       • Steps taken by iWoWSoft
       • Recommended actions for data subjects (e.g. password change, vigilance for phishing)

Specific content and timing of notifications may vary based on the nature and severity of the incident and regulatory guidance in force at the time.

5.8 Post-Incident Review & Improvement

After any SEV1 or SEV2 incident, iWoWSoft performs a post-incident review, led by the Incident Coordinator with management participation. The review typically covers:

• Timeline of events and key decisions
• Root cause and contributing factors
• What worked well and what did not (detection, coordination, communication, technical steps)
• Agreed improvements:
  • Technical controls (e.g. patches, hardening, monitoring)
  • Processes (runbooks, escalation paths, checklists)
  • Training or awareness for staff

Corrective actions are tracked to completion.

6. Interaction with Business Continuity & Disaster Recovery (BC/DR)

The Incident Response Plan and BC/DR Plan are related but distinct:

• Incidents that cause service disruption without data compromise (e.g. network outages, hardware failures with intact disks) are primarily handled via BC/DR, with incident response coordination to manage severity and communication.
• Incidents that involve data compromise or suspected breach (e.g. successful intrusion, ransomware) are handled under this Incident Response Plan, and may also trigger BC/DR actions such as restoring from backup or rebuilding systems.

Our goal in all cases is to:

• Protect customer data,
• Restore service within defined RTO/RPO targets,
• Comply with PDPA and other legal obligations, and
• Communicate transparently with affected customers.

Further details on backups, recovery objectives and worst-case scenarios are available in our Business Continuity & Disaster Recovery Plan (Customer Summary).

7. Testing and Review

To keep the Incident Response Plan effective and aligned with our environment:

• iWoWSoft periodically conducts incident response exercises, which may include:
  • Tabletop simulations of a security incident or personal data breach
  • Combined BC/DR + IR drills, such as restoring from backups after a simulated compromise
• The plan is reviewed:
  • After major SEV1/SEV2 incidents
  • When there are significant changes to systems, hosting provider or legal requirements

Updates are approved by management and communicated internally.

8. Questions

If you have any questions about this Incident Response Plan, or if your organisation has specific incident or breach notification requirements (for example, contractual timelines or formats), please contact our support team or your account manager to discuss how we can align with your needs.