Under the HIPAA Breach Notification Rule, a business associate is treated as having discovered a breach on the first day it is known to the business associate or, with reasonable diligence, would have been known. The rule also says the business associate is deemed to have knowledge if the breach is known to any employee, officer, or other agent of the business associate, other than the person who committed it. For an MSP that handles health data for clients, that means a technician working a night shift who notices something wrong can start the clock for the MSP before anyone senior has heard about it.
Other jurisdictions run on different clocks and different assumptions about who has to notify. This post compares the rules in the United States, Australia, Canada, and the Philippines as they apply to an MSP with offshore staff, and then turns them into a practical internal standard: what a technician reports, how fast, to whom, and what the MSP does next. It is general information and not legal advice. The details depend on the data, the contracts, and the facts of an incident, and a real incident warrants advice from counsel in the relevant country.
Whose Obligation Is It?
Breach notification laws are written around the organization that controls or is accountable for the personal information, and an MSP usually sits one step away from that. Your client is typically the covered entity, the entity subject to the Australian scheme, the organization in control under Canadian law, or the personal information controller under Philippine law. You are the service provider, business associate, or processor. Your technicians, whether they sit in your office or in Manila, are your staff or agents, and the provider that employs an offshore technician may have its own obligations on top.
That structure sets two practical rules. First, the law often puts the duty to notify regulators and individuals on your client, so your job is to give the client fast, complete, and accurate information. Second, your own duties depend on your status and your contracts, and in some cases you have direct obligations as well. Each jurisdiction below handles the split differently, which is why the contract is as important as the statute.
The Rules, Jurisdiction by Jurisdiction
In the United States, the relevant rule for health data is 45 CFR 164.410, published in the Electronic Code of Federal Regulations and reproduced by Cornell's Legal Information Institute. It requires a business associate, following the discovery of a breach of unsecured protected health information, to notify the covered entity without unreasonable delay and in no case later than 60 calendar days after discovery. The notification must include, to the extent possible, the identification of each individual whose information was or is reasonably believed to have been accessed, acquired, used, or disclosed, and the business associate must provide other available information the covered entity needs for its own notices, either at the time or promptly afterward. The 60 days is an outer limit, and a contract can set a shorter period, so read your business associate agreement. A separate section allows notification to be delayed when a law enforcement official states that it would impede an investigation.
In Australia, the Notifiable Data Breaches scheme sits in Part IIIC of the Privacy Act. The Office of the Australian Information Commissioner's quick reference guide, published in June 2026, says the scheme applies to entities with obligations under Australian Privacy Principle 11, which includes government agencies, businesses and not-for-profits with annual turnover above $3 million, private sector health service providers, and some smaller operators. An entity that suspects an eligible data breach must take all reasonable steps to complete an assessment within 30 calendar days of becoming aware of the grounds for suspicion, and where it has reasonable grounds to believe a breach is eligible, it must notify affected individuals and the OAIC as soon as practicable. An eligible breach is one that is likely to result in serious harm and that remedial action has not prevented. Where more than one entity jointly holds the information, only one needs to assess or notify, the entities decide who does, and the OAIC says generally the entity with the most direct relationship with the affected individuals should notify. For an MSP, that is usually the client, and the agreement should say so.
In Canada, the Office of the Privacy Commissioner's guidance on mandatory breach reporting explains that organizations subject to PIPEDA must report to the Commissioner breaches of security safeguards that pose a real risk of significant harm, notify affected individuals as soon as feasible after determining that such a breach has occurred, and keep a record of every breach, whether or not it is reportable, for two years. The guidance addresses processors directly. Where an organization has transferred personal information to a third party for processing, the OPC finds it reasonable to treat the principal organization as having control and therefore responsibility for reporting, and says the principal organization will need to ensure it has sufficient contractual arrangements with the processor to address compliance with the breach provisions. It adds that a processor still has obligations under the Act for information in its own possession or custody.
In the Philippines, the National Privacy Commission's guidance on breach reporting procedures says that the Commission must be notified within 72 hours upon knowledge, or reasonable belief by the personal information controller or processor, that a personal data breach has occurred, and that the obligation to notify remains with the controller even if processing is outsourced or subcontracted. Notification is mandatory when sensitive personal information or information that could enable identity fraud is reasonably believed to have been acquired by an unauthorized person and the controller or the Commission believes there is a likely real risk of serious harm. A full report is due within five days of notification unless the Commission allows more time. The Commission also says all controllers and processors must have a security incident management policy and a response team, and that all security incidents and breaches must be documented, including those that do not require notification. Whether these notification rules apply to data about residents of other countries that is processed in the Philippines is a legal question, and you should not assume they do not. A provider that employs your offshore technician should be able to tell you how its own incident policy works.
| Jurisdiction | Trigger | Timing | Who usually notifies |
|---|---|---|---|
| United States (HIPAA, 45 CFR 164.410) | Discovery of a breach of unsecured protected health information, with knowledge of any employee or agent counted as the business associate's knowledge | Business associate to covered entity without unreasonable delay, and no later than 60 calendar days after discovery | The business associate tells the covered entity, which handles its own onward notices |
| Australia (NDB scheme) | Reasonable grounds to suspect an eligible data breach, meaning likely serious harm that remedial action has not prevented | Assessment within 30 calendar days, then notification as soon as practicable | One entity for jointly held information, generally the one with the most direct relationship with the individuals |
| Canada (PIPEDA) | A breach of security safeguards creating a real risk of significant harm, with a record kept of every breach | As soon as feasible after the organization determines a reportable breach has occurred, records kept for two years | The principal organization in control, which must have contracts that cover the processor |
| Philippines (NPC) | Knowledge or reasonable belief of a breach involving sensitive personal information or identity-fraud data, with likely real risk of serious harm | 72 hours to the Commission and data subjects, full report within five days | The controller, even when processing is outsourced |
Why Offshore Staff Change the Practical Clock
Three features of an offshore arrangement affect how these rules play out. The first is the knowledge rule. The HIPAA text counts knowledge held by an employee or other agent as the business associate's own, and a technician working under your direction is the kind of person that provision describes, although whether a given arrangement counts as agency is a legal question. The practical conclusion is that the moment your technician has information suggesting a breach, you should assume the clock may be running, and the time between their noticing and your hearing is time you may not have.
The second is time zones. Overnight coverage means the first person to see an alert or a report is often a technician working while your decision makers sleep. An incident noticed at 2 a.m. Eastern in a client's mailbox log is seen by your Manila technician at the start of their working day, and if the rule for escalation is to wait for the morning handoff, hours disappear. The third is the number of parties. A client, an MSP, a staffing provider, and an employer of record in the Philippines may each have a role, and without agreed responsibilities, each assumes another one is handling it. Konnect's guide to managing shift handoffs between local and offshore teams covers how to hand work across the time zone gap, and an incident is the case where that handoff matters most.
All four sets of rules are triggered by suspicion or reasonable belief, not by certainty. The OAIC guidance starts the assessment when an entity suspects an eligible breach, and the NPC guidance starts the 72-hour period on reasonable belief. Your internal standard should do the same: a technician reports a suspected incident as soon as it is suspected, and a named person at the MSP decides what it is.
An Internal Timeline That Fits All Four
The table below sets out a response sequence that meets the shortest of these periods, the 72-hour Philippine one, and leaves room within the longer ones. The hour counts are an internal design choice and not a legal requirement, and you should set your own based on your client contracts.
| Window | What happens | Who owns it |
|---|---|---|
| Within one hour of suspicion | The technician reports through one fixed channel, preserves logs and evidence, and takes only the containment steps the runbook allows | The technician, then the on-call incident lead |
| First 24 hours | The incident lead contains the incident, starts a timeline, identifies the affected clients and data, and notifies the client as your contract requires | The MSP incident lead |
| 24 to 72 hours | The client, with your help, assesses whether notification is required, and any Philippine-side obligations are checked with the provider and counsel | The client, with the MSP and counsel |
| Days three to five | Where the rules apply, notifications are sent and any required fuller report is prepared, including identification of affected individuals for HIPAA purposes | The client, supported by the MSP |
| Within 30 days | Any suspected breach assessments are finished, root cause is documented, and controls are corrected | The MSP and the client |
| Afterward | The incident is recorded whether or not it was notifiable, and the record is kept at least as long as the strictest rule that applies, such as Canada's two years | The MSP |
What the Contract Should Say
Because the statutes rely on contracts to allocate the work, the agreement with each client and with your staffing provider should settle several points. First, define the trigger as a suspected incident, not a confirmed one, and state the longest period you may take to tell the other side. The regulatory periods are ceilings and not targets, so choose a period you can actually meet. Second, say what the notice must contain, including the affected systems, the data involved, the individuals identified where possible, the timeline, and the contact person.
Third, state who notifies regulators and individuals, who pays for notification and investigation, and who has the authority to speak to each. Fourth, require cooperation, including log access and retention, evidence preservation, and access to the people involved. Fifth, extend the same obligations to any subcontractor or provider whose staff can touch the data, which the Canadian guidance describes as ensuring contractual arrangements address the breach provisions and the Australian guidance describes through the expectation of an enforceable contract. Sixth, ask your staffing provider for its security incident policy, since the NPC says processors in the Philippines must have one, and for the name of the person who will act on it. These questions apply to any provider, including us.
Preparing the Offshore Team
Rules on paper do nothing if a technician is unsure what counts as an incident. Define the examples in plain terms: a user who entered credentials on a phishing page, a mailbox forwarding rule nobody created, a lost or stolen device, an email sent to the wrong recipient, unusual administrative activity, or a security tool alert that looks real. Give technicians one reporting channel that works around the clock, with a short template that asks what they saw, when, which client and system, and what they have done so far.
Make the standing instruction simple. Report within the hour, do not delete anything, do not reimage a device or wipe logs, do not contact the client or the affected user about the incident unless the runbook says so, and do not decide on your own that something is a false alarm. State clearly that reporting a mistake or a suspected problem will not be punished, because a technician who fears blame will wait, and waiting is the failure this process exists to prevent. Then practice. A short tabletop exercise in which a technician is handed a simulated alert at the end of a shift will show you how long a handoff really takes.
Where This Does Not Fit
This post covers four jurisdictions and one sector rule, and a real incident may involve more. US state breach laws, rules for other sectors such as finance, and laws in other countries have their own definitions and timelines that are not discussed here. Your cyber insurance policy may have its own requirement to notify the insurer promptly, which you should check in the policy text. A law enforcement request can delay a notification under some rules, and a regulator can excuse or postpone one in some circumstances. The 60, 30, and 72 figures above are the limits written into the rules, and regulators expect earlier action where it is possible. Finally, none of this replaces advice from counsel who knows the facts of the incident and the contracts involved.
A Thirty-Day Plan
In the first week, collect every client agreement and business associate agreement with a breach or incident clause, and list the notification periods and responsibilities in each. In the second week, write a one-page internal incident reporting standard covering the one-hour rule, the reporting channel, the template, and the named incident lead for every shift. In the third week, update your staffing provider agreement, or ask the provider for its incident policy and contact, and check your cyber insurance notice terms. In the fourth week, run a tabletop exercise with the offshore team using a simulated overnight alert, time each step, and fix what slows it. Konnect's piece on managing risk when hiring offshore teams covers the wider risk questions that surround this one.
📅 Book a 20-minute call: https://meet.brevo.com/konnectph
✉️ Email us: hello@konnect.ph
If you have offshore staff touching client systems and no written rule for how fast a suspected incident gets reported, bring the breach clause from your largest client agreement or business associate agreement to the call, and we will go through how to set up the reporting standard and handoff for your overnight coverage.
About the Author
Vilbert Fermin is the founder of Konnect, a remote staffing company connecting North American and Australian businesses with top Filipino talent. With deep expertise in IT support and remote team management, Vilbert helps MSPs access skilled technical professionals without the overhead of full-time domestic IT staff. His mission is to showcase Filipino excellence while helping businesses stay protected, productive, and competitive through strategic remote staffing.
