Incident response plan

This document establishes the plan for managing information security incidents and events for Posted, and offers guidance for team members or incident responders who believe they have discovered, or are responding to, a security incident.

This policy covers all information security or data privacy events or incidents affecting Posted, including its services, infrastructure, and the user data it processes. Because Posted processes Google user data, incidents involving Gmail or Google Drive data carry additional notification considerations set out in section 5.

A security event is an observable occurrence relevant to the confidentiality, availability, integrity, or privacy of company controlled data, systems, or networks.

A security incident is a security event which results in loss or damage to the confidentiality, availability, integrity, or privacy of company controlled data, systems, or networks.

Reporting

If a Posted team member, contractor, user, or customer becomes aware of an information security event or incident, possible incident, imminent incident, unauthorized access, policy violation, security weakness, or suspicious activity, they shall immediately report the information using one of the following channels:

• Email security@posted.ai with information or reports about the event or incident

• Email support@posted.ai with information or reports about the event or incident

• Raise an incident in Rootly, which opens and manages the incident channel in Xero's Slack workspace (Posted operates within Xero's Slack)

• Escalate to Xero Security Operations at secops@xero.com, or tag @secops-response in #help-security

Reporters should act as a good witness and behave as if they are reporting a crime. Reports should include specific details about what has been observed or discovered.

The engineering managers and the product lead shall monitor incident and event reports and shall assign a severity based on the following categories.

S3/S4, low and medium severity. Issues meeting this severity are suspicions or odd behaviors. They are not verified and require further investigation. There is no clear indicator that systems are at tangible risk and they do not require emergency response. This includes lost or stolen laptops with disk encryption, suspicious emails, outages, and strange activity on a laptop.

S2, high severity. High severity issues relate to problems where an adversary or active exploitation has not been proven yet, and may not have happened, but is likely to happen. This may include a lost or stolen laptop without encryption, vulnerabilities with direct risk of exploitation, threats with risk of adversarial persistence on our systems such as backdoors or malware, malicious access of business data such as passwords, vulnerability data, or payments information, or threats that put any individual at risk of physical harm.

S1, critical severity. Critical issues relate to actively exploited risks and involve a malicious actor. Identification of active exploitation is required to meet this severity category. Any confirmed unauthorized access to user Gmail or Google Drive data, or to the financial data derived from it, shall be treated as S1.

On-call engineers are notified through PagerDuty. The incident escalation contacts can be found in appendix A.

• S1, critical severity. S1 issues require immediate notification to the engineering managers, the product lead, and Xero Security Operations. Major or critical incidents escalate to Sarah Bennett (GM Security Operations) or Suzy Clark (EGM Security) depending on severity.

• S2, high severity. An S2 ticket must be completed and immediate notification provided to the engineering managers and the product lead.

• S3/S4, medium and low severity. An S3 or S4 ticket must be created and assigned to the appropriate person for response.

After hours, Xero Security Operations can be reached on +1 216 450 6362 (Northern Hemisphere) or +64 9 884 0823 (Southern Hemisphere).

All reported security events, incidents, and response activities shall be documented in Rootly, with the resolution tagged in GitHub.

A root cause analysis may be performed on all verified S1 and S2 security incidents. A root cause analysis report shall be documented and referenced in the incident ticket. The root cause analysis shall be reviewed by an engineering manager, who shall determine if a post-mortem meeting will be called.

For critical issues, the response team will follow an iterative response process designed to investigate, contain exploitation, eradicate the threat, recover systems and services, remediate vulnerabilities, and document a post-mortem with the lessons of the incident.

Summary

- Event reported

- Triage and analysis

- Investigation

- Containment and neutralization (short term work)

- Recovery and vulnerability remediation

- Hardening and detection improvements (lessons learned, long term work)

Detailed

- An engineering manager will manage the incident response effort. For confirmed security incidents, the incident commander should ideally be a member of Xero SecOps Response, in line with Xero's security incident response plan

- The incident will be run in Rootly, which manages the incident channel, roles, and timeline in Slack

- A central war room will be designated, which may be a physical or virtual location such as the Rootly incident channel in Slack

- On-call engineers are paged into the incident through PagerDuty

- A recurring incident response meeting will occur every 2 hours until the incident is resolved

- Xero Legal and management will be informed as needed

Incident response meeting agenda

- Update the incident ticket and timelines

- Document new indicators of compromise

- Perform investigative Q&A

- Apply emergency mitigations

- Plan long term mitigations

- Document the root cause analysis

- Additional items as needed

Special considerations

• Internal issues. Issues where the malicious actor is an internal employee, contractor, vendor, or partner require sensitive handling. The incident manager shall contact the product lead and Xero Security Operations directly and will not discuss the issue with other team members. These are critical issues where follow-up must occur.

• Compromised communications. Incident responders must have Slack messages arranged before listing themselves as incident members. If there are IT communication risks, an out of band solution will be chosen and communicated to incident responders by phone, using the numbers in appendix A.

• Google user data. If an incident involves actual or suspected unauthorized access to data obtained through Google APIs, the response must include an assessment of notification obligations to affected users, to Google, and under applicable US state breach notification laws. This assessment shall be made with Xero Security Operations and Xero Legal.
  

Additional requirements

- Suspected and reported events and incidents shall be documented.

- Suspected incidents shall be assessed and classified as either an event or an incident.

- Incident response shall be performed according to this plan and any associated procedures.

- All incidents shall be formally documented, and a documented root cause analysis shall be performed.

- Suspected and confirmed unauthorized access events shall be reviewed by the incident response team. Breach determinations shall only be made by Xero Security Operations in conjunction with Xero Legal.

- Posted shall promptly and properly notify customers, users, affected parties, and regulatory agencies of relevant incidents or breaches in accordance with Xero policies, contractual commitments, and regulatory requirements.

- This incident response plan shall be reviewed and tested at least annually.

Every team member and user of any Posted information resources has responsibilities toward the protection of the information assets. The table below establishes the specific responsibilities of the incident responder roles.

Response team members

Incident manager: The incident manager is the primary and ultimate decision maker during the response period, and is ultimately responsible for resolving the incident and formally closing incident response actions. See appendix A for contact information. Responsibilities include: ensuring the right people from all functions are actively involved at all times; communicating status updates to the appropriate people at regular intervals; resolving incidents in the immediate term; determining necessary follow-up actions; assigning follow-up activities to the appropriate people; and promptly reporting incident details which may trigger breach reporting, in writing, to Xero Security Operations.

Incident response team: The individuals who have been engaged and are actively working on the incident. All members remain engaged in incident response until the incident is formally resolved, or they are formally dismissed by the incident manager.

Engineers: Qualified engineers will be placed into the on-call rotation in PagerDuty and may act as the incident manager (if primary resources are not available) or a member of the incident response team when engaged to respond to an incident. Engineers are responsible for understanding the technologies and components of the information systems, the security controls in place including logging, monitoring, and alerting tools, appropriate communications channels, incident response protocols, escalation procedures, and documentation requirements.

Team members: Employees and contractors working on Posted. Responsible for following policies and reporting problems, suspected problems, weaknesses, suspicious activity, and security incidents and events.

Users: Posted users are responsible for reporting problems with their use of Posted, via support@posted.ai, and for verifying that reported problems are resolved.

Xero Legal: Responsible, in conjunction with Xero Security Operations and management, for determining if an incident shall be considered a reportable breach. Legal is involved for reporting decisions, disclosure obligations, and customer or regulatory notifications, and shall review and approve in writing all external breach notices before they are sent to any external party. Legal support is requested through the Legal Help Hub, with legalteam@xero.com as the backup inbox.

Xero Security Operations: Responsible for breach determinations in conjunction with Xero Legal, and for directing the response where an incident extends beyond Posted. Posted shall seek stakeholder consensus when determining whether a breach has occurred; Xero Security Operations makes the final determination if consensus cannot be reached.

Executive commitment

Management has approved this policy and commits to providing the resources, tools, and training needed to reasonably respond to identified security events and incidents with the potential to adversely affect Posted, Xero, or their customers.

Requests for an exception to this policy must be submitted to and authorized by an engineering manager for approval. Exceptions shall be documented.

Any known violations of this policy should be reported to the product lead. Violations of this policy may result in immediate withdrawal or suspension of system and network privileges and disciplinary action in accordance with company procedures, up to and including termination of employment.

July 1, 2026 | First version | Matt Stephanou | Ele Kyriazis |

Appendix A: contact information

Contacts for incident escalation:

Gareth MacBeth | Engineering manager | gareth@posted.ai, gareth.macbeth@xero.com | +27 71 685 3708

Jamie Burns | Engineering manager | jamie@posted.ai, jamie.burns@xero.com | +27 71 865 2081

Jodilee Manuel | Product lead | jodilee@posted.ai, jodilee.manuel@xero.com | +27 83 963 6105

Xero Security Operations (SecOps Response) | Security escalation | secops@xero.com, or @secops-response in #help-security | After hours: +1 216 450 6362 (Northern Hemisphere), +64 9 884 0823 (Southern Hemisphere)

Sarah Bennett | GM Security Operations (major or critical incidents) | Via SecOps Response | Via SecOps Response

Suzy Clark | EGM Security (major or critical incidents) | Via SecOps Response | Via SecOps Response

Xero Legal | Legal support | Legal Help Hub (primary), legalteam@xero.com (backup) | Via Legal Help Hub

Appendix B: incident collection form

General information

Incident detector's information

- Name:

- Title:

- Phone:

- Email:

- Date and time detected:

- Location incident detected from:

- Additional information:

Type of incident detected:

- [ ] Denial of service

- [ ] Malicious code

- [ ] Unauthorized use

- [ ] Unauthorized access

- [ ] Espionage

- [ ] Probe

- [ ] Hoax

- [ ] Other:

Incident location

- Site:

- Site point of contact:

- Phone:

- Email:

How was the incident detected:

Additional information:

Location(s) of affected systems:

Date and time incident handlers arrived at site:

### Affected systems

Describe affected information system(s), one form per system is recommended:

- Hardware manufacturer:

- Serial number:

- Office location:

- Is the affected system connected to a network? Yes / No

Describe the physical security of the location of affected information systems (locks, security alarms, building access):

### Isolation

- Approval to remove from network? Yes / No

- If yes, name of approver:

- Date and time removed:

- If no, state the reason:

### Backup of affected system(s)

- Last system backup successful? Yes / No

- Name of persons who did backup:

- Date and time last backups started:

- Date and time last backups completed:

- Backup storage location:

### Incident eradication

- Name of persons performing forensics:

- Was the vulnerability (root cause) identified? Yes / No

- Describe:

- How was eradication validated: