A small business does not need to operate a large IT department to handle personal information. It may collect customer names, telephone numbers, email addresses, enquiry details, employee records or supplier contact information as part of ordinary operations.
That information creates responsibilities.
A security compromise can happen through a cyberattack, a lost device, an email sent to the wrong recipient, inappropriate access or a failure to protect records properly. The consequences may extend beyond technology: customers can be affected, operations may be disrupted and the business may need to take formal notification and recovery steps.
The time to decide who does what is before an incident occurs.
A written response plan helps staff recognise a possible compromise, escalate it to the right person, preserve relevant information and follow an organised process.
For South African businesses, the Protection of Personal Information Act (POPIA) and the Information Regulator's guidance are important starting points. This article explains how to document a practical response process without treating a template as a substitute for legal or specialist security advice.
1. Understand what a security compromise can involve
The Information Regulator describes a security compromise as an event affecting the security, confidentiality, integrity or availability of personal information, including accidental or unlawful loss, destruction, alteration, disclosure, processing or access.
Examples include:
- Sending personal information to the wrong email recipient.
- Losing paperwork or a device containing inadequately protected information.
- A cyberattack that exposes or alters personal information.
- Unauthorised access by an employee or another person.
- Sharing passwords or leaving personal information accessible to unauthorised people.
A compromise does not have to begin with an advanced cyberattack. Ordinary operational mistakes can also expose information.
The Information Regulator's Fact Sheet: Handling of Security Compromises explains examples of compromises and the notification process.
Your procedure should therefore cover both digital and physical records. A business that stores customer details in email, paper forms and spreadsheets needs a process that applies to all those environments.
2. Assign responsibility before an incident occurs
A response plan should make it clear who receives the first report and who has authority to coordinate the response.
Under the Information Regulator's guidance, the Information Officer or Deputy Information Officer should report a security compromise to the Regulator and affected data subjects on behalf of the responsible party.
The exact roles and internal reporting lines will depend on the organisation. Document them clearly instead of assuming that every employee knows whom to contact.
A useful responsibility table might look like this:
| Role | Responsibility to document |
|---|---|
| Employee or person discovering the issue | Report the suspected compromise promptly and preserve relevant information |
| Incident coordinator | Maintain the incident record and coordinate internal actions |
| Information Officer or Deputy Information Officer | Coordinate the required assessment and notification process |
| IT or security support | Help contain the incident, investigate affected systems and restore services |
| Management | Approve appropriate resources and operational decisions |
| External service provider or operator | Notify the responsible party promptly when a compromise affects information processed on its behalf |
In a small business, one person may perform several internal functions. The important point is that responsibilities are assigned and understood.
The response plan should include current contact details and an alternative contact if the primary person is unavailable.
3. Document the first-response procedure
Staff need simple instructions they can follow under pressure.
A first-response checklist should explain what to do when someone suspects that personal information has been compromised.
Step 1: Report the incident immediately
Provide a clear reporting route, such as a designated business email address or direct contact with the incident coordinator.
Staff should not be expected to determine the full legal classification of an event before reporting it internally.
The procedure should encourage prompt escalation, even if the available information is incomplete.
Step 2: Protect people and limit further exposure
Depending on the incident, practical steps may include disabling a compromised account, revoking exposed credentials, restricting access to affected records or isolating an affected system with appropriate technical assistance.
The response should avoid destroying information needed to understand the incident.
Do not instruct untrained staff to take risky technical actions that could worsen the situation. The plan should explain when to involve qualified IT or security support.
Step 3: Preserve relevant evidence
Record what was observed and when. Preserve relevant messages, system alerts, access logs and other available records in a controlled manner.
Avoid circulating copies of exposed personal information unnecessarily. The investigation should use the minimum information needed by authorised people.
Step 4: Notify the designated responsible people
Escalate the issue to the incident coordinator and Information Officer or Deputy Information Officer according to the documented process.
If a third-party operator discovers a compromise involving information controlled by the business, the operator must notify the responsible party. The contract and incident procedure should make this communication route clear.
4. Record the facts without delaying urgent action
The business needs a reliable record of what happened, what is known and what remains uncertain.
Create an incident register with fields such as:
| Field | Information to record |
|---|---|
| Incident reference | A unique internal identifier |
| Date and time discovered | When the issue was first identified |
| Reporter | The person or system that raised the alert |
| Incident summary | A factual description of the suspected compromise |
| Information involved | Categories of personal information potentially affected |
| Systems or records | Relevant applications, devices, files or physical records |
| People potentially affected | The known or estimated scope, where established |
| Immediate actions | Steps taken to limit further exposure |
| Responsible contacts | People notified internally and externally |
| Notification record | Dates, methods and references for required notifications |
| Outstanding questions | Facts that still need investigation |
| Remediation | Corrective actions and their status |
| Closure review | Findings, approvals and lessons learned |
Restrict access to this register because it may contain sensitive incident details.
Record facts separately from assumptions. For example, note that an account was accessed at a particular time if that is supported by logs, but do not describe information as stolen unless the evidence supports that conclusion.
This discipline helps the business investigate the incident without presenting unverified conclusions as established facts.
5. Know the notification principle
POPIA section 22 addresses notification of security compromises.
The Information Regulator's published guidance states that security compromises must be reported regardless of their perceived risk level. It also explains that the responsible party should notify the Regulator and affected data subjects as soon as it is reasonably sure that a compromise has occurred.
This has an important operational consequence: the business should not automatically wait for a complete forensic investigation before escalating the notification process.
The information available at the beginning may be incomplete. The Regulator's guidance advises reporting as soon as reasonably practicable using the information available and updating the notification as further information becomes available.
The response plan should therefore define a prompt decision and escalation process rather than requiring staff to finish every investigative task first.
Read the Information Regulator's security compromise fact sheet and the official Protection of Personal Information Act 4 of 2013 when preparing your procedure.
This article is general operational guidance, not legal advice. Businesses should confirm how the law and current regulatory guidance apply to their circumstances.
6. Document the notification workflow
The response plan should identify who coordinates the notification process and where the required submissions are made.
According to the Information Regulator, security compromise notifications under section 22 have been submitted through its eServices portal since 1 April 2025.
The official Information Regulator eServices portal provides a service for reporting security compromises.
Document the following in your internal procedure:
- Who prepares and coordinates the notification.
- Who is authorised to submit it.
- Which official portal or current reporting channel must be used.
- What facts and supporting information should be collected.
- How submission references and copies are retained.
- Who coordinates communication with affected data subjects.
- How additional information will be recorded and supplied when needed.
Do not store portal passwords in the procedure itself. Record the responsible role and the approved secure method for obtaining access.
The notification process should be reviewed against the Regulator's current instructions. Avoid relying indefinitely on an old form, saved screenshot or procedure that has not been checked for changes.
7. Prepare for communication with affected people
A notification process should address both the Regulator and affected data subjects, as applicable under the relevant requirements.
The Information Regulator's guidance explains that communication to data subjects should describe what happened and when, what steps are being taken to mitigate the impact, what advice may help the affected people and other relevant information that is known.
Your internal plan should identify who prepares the communication and how it is checked before it is sent.
The exact wording depends on the incident. A lost device, an incorrectly addressed email and an intrusion into a business application may involve different facts and different practical advice.
Prepare a communication checklist rather than a single message that assumes every incident is the same.
It should prompt the responsible people to verify:
- What is known about the event.
- Which categories of information may be affected.
- Which people may need to be notified.
- What the business has done to limit further exposure.
- What practical guidance affected people may need.
- Which contact route can be used for questions.
- Whether further communication may be required.
Avoid disclosing additional personal information while explaining the incident. Have the appropriate responsible person review the proposed communication and seek specialist advice when necessary.
8. Include suppliers and external operators
Many small businesses depend on external providers for email, hosting, customer management, payroll, cloud storage and other services.
A business should know which providers process personal information on its behalf and how to reach them during an incident.
Maintain a supplier register with:
- Provider and service name.
- Type of information handled.
- Business contact and emergency escalation route.
- Relevant contract or processing agreement.
- Provider notification requirements.
- Responsibilities for investigation and remediation.
- Available logs, reports or other evidence.
- Procedure for ending access when the relationship ends.
POPIA places responsibilities on responsible parties and also addresses the obligations of operators. The Information Regulator's guidance states that an operator must notify the responsible party when a compromise affects personal information it processes on that party's behalf.
Make sure the relevant agreements and operating procedures support this communication.
A contract alone is not a response plan. Staff still need to know whom to contact, what information to request and how to escalate an incident outside normal business hours where necessary.
9. Plan containment, recovery and prevention
Notification is only one part of the response.
The business also needs to address the cause of the incident, reduce further exposure and restore affected operations safely.
Depending on the circumstances, actions may include:
- Resetting compromised credentials.
- Reviewing access permissions.
- Applying security updates.
- Restoring systems from verified backups.
- Recovering lost or altered records.
- Correcting a mistaken disclosure where possible.
- Reviewing the security of supplier integrations.
- Training staff on a process that failed.
- Revising technical or organisational safeguards.
Record who is responsible for each corrective action and when it is due.
Do not close the incident merely because the website or application is working again. The business should also review whether the exposure has been contained, required notifications have been handled and further corrective work remains.
After the incident, conduct a review focused on learning rather than assigning blame without evidence.
Ask what allowed the incident to happen, whether the response process worked and which changes would reduce the likelihood or impact of a similar event.
10. Test the procedure before it is needed
A document can appear complete while leaving staff unsure what to do in practice.
Run a simple tabletop exercise using a hypothetical incident. For example, imagine that an employee sends a spreadsheet containing customer contact information to the wrong recipient.
Ask the team:
- Who receives the first report?
- What information must be recorded immediately?
- Who decides which response actions are appropriate?
- Who must be notified internally?
- How will the Information Officer be contacted?
- Where will the incident and notification records be stored?
- How will the business verify that corrective actions are completed?
The exercise should test the process, not expose real customer data.
Record any gaps and update the procedure. Review it when staff responsibilities, suppliers, systems or relevant regulatory guidance change.
11. A practical document pack for a small business
A small business does not necessarily need a lengthy manual. A concise, well-maintained pack may be more useful than a complex document that nobody follows.
Consider maintaining the following:
| Document | Purpose |
|---|---|
| Security compromise response procedure | Defines the sequence of actions |
| Roles and contact register | Identifies the people responsible for the response |
| Incident register template | Records the facts and decisions |
| Personal information inventory | Helps identify what information is held and where |
| Supplier and operator register | Identifies external services and escalation routes |
| Notification checklist | Helps coordinate required communications |
| Recovery checklist | Records containment and restoration tasks |
| Post-incident review template | Captures lessons and corrective actions |
| Staff reporting instructions | Explains how employees raise a concern |
These documents should be proportionate to the business. A small professional practice may have a simpler system than a business processing large volumes of sensitive information, but both need a clear process appropriate to their risks and obligations.
Store the documents securely, control who can edit them and maintain version information so staff can identify the current procedure.
Mogen's Business Documentation
If your business needs clearer procedures, forms and operational templates, explore Mogen's business documentation service. Legal or specialist review may be appropriate for compliance-specific requirements.
Frequently asked questions
Does every small business need a written incident response plan?
The appropriate documentation depends on the business's operations, information and obligations. A written procedure is a practical way to establish responsibilities and make the response repeatable. Businesses should confirm the specific requirements that apply to them.
Should a business wait until a security compromise is fully investigated before reporting it?
The Information Regulator's published guidance says the responsible party should notify the Regulator and affected data subjects as soon as it is reasonably sure a compromise has occurred. It also advises reporting with the information available and updating the notification as more facts emerge. Confirm the current requirements for your situation.
What if the incident occurs at a service provider?
The business should have an agreed route for the provider to notify the responsible party promptly. The responsible party should then follow its documented assessment and notification process in accordance with the applicable requirements.
Is a lost laptop automatically a reportable security compromise?
A lost device may involve a security compromise if personal information is affected. The facts matter, including what information was stored, how it was protected and what is known about access. The Information Regulator's guidance states that security compromises must be reported irrespective of their perceived risk level. Seek appropriate advice when assessing a specific incident.
Can a business use a template from the internet?
A template can be a starting point, but it should be adapted to the business's actual systems, roles, suppliers and procedures. Check that it reflects current official guidance and does not promise compliance simply because a form has been completed.
Review your operational documentation
If your business needs help organising its policies, procedures and internal records, contact Mogen to discuss the documentation required for your operations.
Conclusion
A security compromise can create confusion at precisely the time a business needs to act clearly and promptly.
A documented response plan helps staff report incidents, preserve relevant information, contact the right people and coordinate containment, notification and recovery. It also makes it easier to learn from an incident and improve the safeguards that protect personal information.
Start by documenting responsibilities, a practical first-response checklist and a reliable incident register. Add supplier contacts, notification steps and recovery procedures that reflect the way your business actually operates.
Review the plan periodically and check it against current Information Regulator guidance. The objective is not simply to possess a policy, but to make sure authorised people can follow it when it matters.