DEV Community: Karnav Thakar

Data Classification Policy: How to Write One That Staff Follow

Karnav Thakar — Fri, 30 Oct 2026 10:41:35 +0000

A data classification policy is one of the shortest documents in an information security program and one of the most often skipped. Without it every file gets treated the same way, so either everything is locked down and work slows, or nothing is and sensitive data ends up in the wrong place. Here is how we set one up with Australian teams.

1. Choose three or four levels

More levels do not make a better policy, they make one nobody remembers. A common set is public, internal, confidential and restricted. Write each level in plain words and give an example staff will recognise: a published price list is public, a team meeting agenda is internal, payroll files and customer contracts are confidential, and health records or credentials are restricted.

2. Write handling rules next to each level

A label means nothing without instructions. For each level, state where the data can be stored, who can access it, whether it can be emailed or shared outside the company, whether it must be encrypted, and how it is destroyed. Keep this to a single table so people can check it in a few seconds.

3. Give every data set an owner

Classification should be decided by the person who understands the data, not by IT. Assign an owner to each data set, such as customer records or financial reports, and have them set its level. Where nobody decides, treat unlabelled data as internal so work is not blocked.

4. Link it to your risk register

The level drives how much protection a data set needs, so it belongs in your risk assessment. Restricted data with weak access controls is a high-rated risk with a named owner and a treatment date. Our ISO 27001 risk register template has the columns to record that.

5. Train staff and spot-check

Brief everyone on the levels, then check once a quarter. Ask a few people what level their own files are. If they cannot answer, the scheme is too complicated and needs simplifying, not a longer training session.

6. Review it every year

Classifications change as systems and suppliers do. Review the policy and the data set levels at least annually, and record the date and approver. Auditors usually ask for that evidence.

If you want a starting draft, our security policy templates page has a short guide to writing one, alongside a starter policy pack. For help applying it, contact Cyber Compliance Pro.

A Ransomware Incident Response Plan Your Team Can Actually Follow

Karnav Thakar — Mon, 26 Oct 2026 17:30:30 +0000

Most ransomware plans fail on decisions, not technology. Here is a short checklist for the first hour and beyond.

First hour

Confirm the incident and rate its severity.
Isolate affected systems from the network, and do not power them off until evidence is captured.
Name an incident lead, a technical lead and a communications lead, each with a backup.
Preserve logs, ransom notes and disk images.

Notify

Your cyber insurer and legal counsel.
The national cyber agency (in Australia, the ACSC).
Regulators and affected people where notification duties apply.

Recover

Restore from tested, offline backups before reconnecting anything.
Reset credentials and review privileged access.
Run a lessons-learned review and update the plan.

Rehearse the plan at least once a year with a tabletop exercise, because the first real attempt should not be the first time anyone reads it.

Full playbook with roles, reporting duties and recovery steps: https://cybercompliancepro.com/blog/cyber-attack-incident-response-plan-ransomware-playbook/

ISO 27001 Internal Audit: A Practical Checklist Before Your Certification Audit

Karnav Thakar — Fri, 09 Oct 2026 08:44:53 +0000

An ISO 27001 internal audit is the last test before an external auditor arrives, and it is where most organisations discover how much of their ISMS exists only on paper. Clause 9.2 requires audits at planned intervals, but the standard says little about how to run one that is actually useful. This is the approach we use with Australian teams.

1. Fix the scope and the criteria first

Write down what the audit covers (which sites, systems, teams and processes) and what it is measured against: the ISO/IEC 27001 clauses, your own policies and the controls in your Statement of Applicability. An audit with no stated criteria produces opinions, not findings.

2. Keep the auditor independent

Auditors cannot review their own work. In a small company that usually means a different team member or an outside consultant for the areas they normally run. Record who audited what and why they were independent.

3. Work from a checklist, but sample real evidence

A checklist keeps coverage consistent. The evidence is what matters. For each control, ask to see the record, not the policy: a signed access review, a closed change ticket, a restore test log, an onboarding checklist for a recent starter. Sample a few items rather than checking every one.

Our ISO 27001 internal audit checklist lists the clause-level questions and the evidence to request for each.

4. Check the clauses people forget

Controls get the attention, but auditors also test the management system itself:

Is the risk assessment current, and does it match the Statement of Applicability?
Has the risk treatment plan been approved by the risk owners?
Are security objectives measured, and who reviewed the results?
When was the last management review, and did it produce actions?
Are nonconformities from the last audit closed with evidence?

5. Write findings that can be fixed

Classify each finding as a major nonconformity, minor nonconformity or opportunity for improvement. State the requirement, what you saw and the evidence. "Access reviews are inadequate" cannot be fixed. "The Q2 access review for the finance system was not performed, contrary to the access control policy" can.

6. Finish the fixes before the external audit

Assign an owner and a due date to each finding, track root cause rather than just the symptom, and keep the corrective action records. Certification bodies often ask to see the last internal audit report and how its findings were handled, so complete this before Stage 2.

Timing

Most organisations run the internal audit and management review a few weeks before the certification audit, which leaves time to fix findings. If you are still planning the certification itself, see the ISO 27001 certification overview for the typical stages.

If you would like an independent review of your ISMS before the external audit, contact Cyber Compliance Pro.