Techly Incident Management Policy

Purpose

This policy sets out how Techly Operations Pty Ltd (Techly) finds, contains and recovers from incidents affecting Pyron, who it tells and when, and how it learns from each one.

Scope

An incident is any event that harms, or could harm, the confidentiality, integrity or availability of Pyron or of the information in it. That includes:

• unauthorised access to Customer Data, or its loss or disclosure;
• a compromised credential, device or account with access to Techly's systems;
• malware, or an attack on Pyron or its providers;
• an outage, or a fault that stops customers using Pyron or loses their work;
• a security control found not working.

It also covers the reports Techly receives from outside: vulnerability reports, complaints and notices.

How incidents are found

• Alerts. Pyron's logs, metrics and traces are watched by alert rules in Grafana Cloud. Every alert has a written runbook saying what it means, what to check first and how to fix it. Serious alerts page the on-call engineer through All Quiet, at any hour, and the rest post to Techly's alerts channel.
• Security events in AWS. Use of emergency administrator access, a sign-in as an account's root user, a change to the organisation's policies, a change to AWS CloudTrail, a change to access assignments, and new outside access to a resource each raise an alert. The first four page the on-call engineer.
• Errors. Application errors are reported to Sentry.
• Uploaded files. Every uploaded file is scanned for malware, and a file found to be malicious is quarantined.
• Checks from outside. Synthetic checks test Pyron from outside, and a watchdog pages if the monitoring itself stops reporting.
• People. Customers, staff and security researchers report what they see (below).

Reporting an incident

• Customers write to Teams@techly.au, or to their usual Techly contact.
• Security researchers write to security@pyron.io, the address in Pyron's security.txt, or to Teams@techly.au. Clause 10 of the Website Terms sets out what good-faith reporting means.
• Staff tell the Technical Director straight away, by phone if it is urgent.

Severity

Severity	Examples	Response
Critical	Customer Data reached by someone not entitled to it, or lost; a credential with access to production compromised; Pyron unavailable to every customer	Paged, and handled at once, at any hour
High	A suspected incident affecting Customer Data; one customer unable to use Pyron; a security control found not working	Handled the same day
Medium	Degraded performance; a vulnerability with no sign it has been used	Handled within the working week
Low	A fault with a workaround; a report that turns out not to be an incident	Recorded and scheduled

The on-call engineer sets the severity, and raises it as soon as there is reason to.

Handling an incident

1. Contain. Stop the harm first: revoke sessions and credentials, block traffic, switch off the feature or automation involved.
2. Investigate. Work out what happened, from what, and to whose data, using the workspace's audit trail, AWS CloudTrail, Pyron's logs and error reports. Preserve the evidence.
3. Fix. Recover through the normal change process. Techly fixes forward: a bad change is corrected by a new change, through the same checks as any other (Techly Change Management Policy).
4. Tell. Notify the people who need to know (below).
5. Learn. Review it (below).

Each incident is recorded in Techly's issue tracker with its timeline, its cause and its follow-up actions.

Telling customers

We notify an affected customer of a suspected or confirmed security incident affecting their data without undue delay and no later than 48 hours.

The Technical Director, or the Managing Director if he cannot, tells the customer's contacts by email: what happened, what data is affected, what Techly has done and what the customer may need to do. Techly keeps the customer informed until the incident is closed.

Data breaches

Where personal information is involved we assess whether an eligible data breach has occurred under Part IIIC of the Privacy Act 1988 (Cth), within 30 days and sooner where we can, and notify the Office of the Australian Information Commissioner and affected individuals where the test is met. Where we act as processor, the customer notifies the individuals.

The Data Protection Officer makes the assessment and the decision to notify, and records both, including when the answer is that no notification is needed (Techly Data Protection and Privacy Policy).

Reports, complaints and notices

What	Acknowledged within	Answered within
A vulnerability report	5 business days	Kept informed until it is resolved
A notice about material on the website, under clause 15 of the Website Terms	5 business days	20 business days, or we say why it needs longer
A request to access or correct personal information	5 business days	30 days
A grievance from a person in India	3 business days	15 days

A report that describes an incident is handled as one.

After an incident

Every Critical or High incident gets a written review within 10 business days of being closed: the timeline, the cause, what worked and what did not, and what changes. Each change is tracked to completion. A lesson that changes how Techly works goes into the runbook, the documentation or the code it concerns, so it is not lost. An affected customer may ask for a summary of the review.

Once a year the directors walk through one incident scenario together, and update this policy and the runbooks from what they find.

Who is responsible

• The Technical Director owns this policy, is the on-call engineer, and leads every incident.
• The Managing Director stands in to tell customers when the Technical Director cannot.
• The Data Protection Officer decides on notifying a data breach.

Review

The Technical Director reviews this policy every year, and after every Critical incident.