Incident Response Policy

1. Scope and definitions

This policy covers the RealEstAi platform, the cloud and source-control accounts that run it, company email, vendor consoles and any device that can reach them.

• Event. Anything noticed that might matter: an alert, an odd log entry, a customer’s question, a provider’s notice. Every event is recorded and looked at; most are not incidents.
• Incident. An event that has harmed, or is reasonably likely to harm, the confidentiality, integrity or availability of the platform or of information we hold.
• Privacy breach. The loss of, or unauthorized access to, or disclosure of, personal information, in the words of Alberta’s Personal Information Protection Act (PIPA), section 34.1. A breach does not need an attacker: a misdirected email is one.

2. Severity

Severity sets urgency. Whether an incident is a privacy breach is a separate question, asked every time.

3. How we respond

1. Detect and triage. An incident log is opened with a reference, the time, the source of the report and what was seen. The report is verified against the source logs, a severity is assigned, and we ask at once whether personal information and which firms could be involved.
2. Contain. The smallest action that stops the harm: deactivate a user, suspend a firm, revoke and reissue a credential, cancel outstanding download links, disable an endpoint, or stop the service. Accounts and records are deactivated, never deleted, so that evidence survives.
3. Preserve evidence. Audit records, support-access records, download and sign-in events, request metrics, traces, Azure activity logs, deployment history and provider delivery logs are exported to dated files before anything is cleaned up. Where records may have been altered, a copy of the database is restored inside the seven-day window and kept.
4. Eradicate and recover. The cause is found and stated in plain words, fixed, deployed and confirmed in production. The same weakness is looked for elsewhere. Every credential the attacker could have seen is rotated. Access is re-enabled in stages while the audit log is watched.
5. Notify (section 4).
6. Review. Every Severity 1 or 2 incident and every privacy breach gets a written review: the timeline, the cause, what worked, what was missing, and actions with owners and dates. The affected firms receive the written report.

4. Who is told, and in what order

1. The affected firm, first and promptly. As soon as we have confirmed, or have good reason to believe, that a firm’s information was lost or accessed or disclosed without authority. We send what is known, say what is not, and update. Email, and a phone call for Severity 1 and 2.
2. Regulators, for information under RealEstAi’s own control, where the legal test is met.
3. Individuals, as the law and the firm’s decisions require.
4. Others as needed: a provider, the hosting or source-control platform, the police, an insurer.

Outside communication states facts and states what is not yet known. A copy of everything sent is kept in the incident log. We make no public statement naming a firm without its consent.

5. Privacy breaches under Alberta law

For information on a client file, the firm is the organization with control of the information, and RealEstAi is its service provider. The duty to notify the Information and Privacy Commissioner of Alberta under PIPA section 34.1 therefore rests with the firm; RealEstAi’s job is to give the firm the facts promptly and in enough detail for the firm to make its own assessment. For information RealEstAi controls itself, such as platform accounts and billing contacts, RealEstAi assesses, decides and notifies.

What we give an affected firm:

• the facts, fast, in a format that follows the headings of the Commissioner’s notice, with updates as they firm up;
• log extracts limited to that firm’s users and matters;
• one named contact for the life of the incident;
• reasonable availability to the firm’s counsel, insurer and forensic advisers;
• a written incident report after closure.

The test for notifying the Commissioner is whether a reasonable person would consider there is a real risk of significant harm to an individual; our practice is to write out the reasoning rather than a one-word rating, and where it is genuinely unclear, to report. Notice is given without unreasonable delay, in writing, with the content prescribed by the PIPA Regulation. Where federal law applies, the Privacy Commissioner of Canada is notified as soon as feasible and affected individuals are notified directly.

6. The breach register

Every privacy breach is entered in a register, whether or not it was reportable, including near misses where information was exposed but not seen. Each entry records when it was discovered, occurred, contained and closed; what happened and why; the types of information and the firms involved; the estimated number of individuals; the risk-of-harm assessment with its reasoning and who made the decision; when the Commissioner, the firms and individuals were notified; and the follow-up actions. Entries cannot be deleted, every change is recorded with the values before and after, and the register can be exported for the Commissioner or an auditor. Entries are kept for at least 24 months from the date the breach was determined.

7. Contacts

• Security incidents: contactus@realestai.ca.
• Privacy matters: privacy@realestai.ca.

8. Review

This policy is reviewed on a regular cadence and after every Severity 1 or 2 incident.