Security work necessarily involves handling the same tools that attackers use. Section 16(2) of the Cybercrime Code Act 2016 recognises that.
Section 16(2) and (3)
It is a defence to a charge under this section where the design, production, sale, procurement for use, import, distribution or otherwise making available, or possession of devices referred to in subsection (1) is for authorised testing or protection of an electronic system or device, or for law enforcement purposes.
Section 16(3): Whether an illegal device referred to in subsection (1) is for authorised testing, protection of an electronic system or device, or law enforcement purposes, is a question of fact.
Authorised testing. Penetration testing, vulnerability assessment, red team exercises — where authorised.
Protection of an electronic system or device. Defensive work — building and running security tooling, analysing malware to defend against it, hardening systems.
Law enforcement purposes. Police and prosecuting authorities using tools in investigations — consistent with the section 41 power to authorise remote forensic software and hardware.
The limits of the defence
The opening words are “a charge under this section”. The defence does not extend to any other offence in the Act.
So a tester who, in the course of a test, accesses a system commits section 6; who intercepts traffic commits section 7; who alters or deletes data commits section 8; who disrupts a service commits section 9; and who obtains protected data commits section 10 — unless there is a lawful excuse for each of those acts.
For those offences, the protection is not section 16(2) but the general element in each: acting with a lawful excuse or justification, and not in excess of it. That excuse comes from the authorisation of the system owner.
Read carefully, the phrase is “for authorised testing or protection of an electronic system or device, or for law enforcement purposes”. The word authorised attaches to testing.
Whether it also qualifies protection is a matter of construction, but the safe assumption for anyone relying on the defence is that authority will be expected in every case. Section 16(3) makes the question one of fact, so what will matter is the evidence of what the purpose actually was.
Proving the purpose
That has two consequences. There is no technical test to satisfy — the court looks at the reality. And the person relying on the defence needs evidence, not assertion.
What that means in practice for a security professional:
- Written authorisation before starting. From the owner or controller of the system, identifying who is authorised, what systems are in scope, what techniques are permitted, and over what period.
- Scope discipline. The Act repeatedly catches conduct in excess of a lawful excuse. Testing outside the authorised scope loses the protection for the other offences and undermines the section 16(2) purpose.
- Records. Contemporaneous logs of what was done, when, and under what authority.
- Tool handling. Because section 16(1) covers possession and procurement for use, tools should be held under controlled conditions and not distributed beyond the engagement.
- Reporting rather than exploiting. A finding disclosed to the owner supports the protective purpose; a finding retained or sold does not.
A gap worth noting
Section 16(2) is the only express defence of this kind in the Act. There is no equivalent for:
- Security research conducted without the system owner’s authorisation — even where the purpose is to identify and report a vulnerability;
- Journalism — though note the public interest defences elsewhere in the Act: section 17(2), section 18(3), section 21(5) and section 25(3), each of which turns on the benefit of the public;
- Academic study of systems or malware, unless it falls within “protection of an electronic system or device”.
A researcher who probes a system without authority is therefore exposed under section 6 whatever their motive — and, if the probing was for the purposes of gaining unauthorised access, falls within the section 2 definition of “hacking”.
The practical rule is unavoidable: get authorisation in writing first. Coordinated disclosure programmes, bug bounty terms and testing agreements are what convert research into authorised testing.
A caution for ICT service providers
Section 44(1)(a) makes it a crime for an ICT service provider to monitor the information which they transmit or store on behalf of their users, or to actively seek facts or circumstances indicating illegal activity by their users, without lawful excuse — carrying up to 25 years or K100,000, and K1,000,000 for a company.
Section 16(2) does not answer that charge, because it applies only to section 16. A provider conducting security monitoring needs a lawful excuse of its own — typically consent in its terms of service, or a court order under Part IV.
Sources
- Cybercrime Code Act 2016 — ss 2, 6–10, 16, 17, 18, 21, 25, 41, 44
Before relying on anything here, read the current text of the Cybercrime Code Act 2016 and check for later amendments. If a decision matters to you, get advice — start with the Office of the Public Solicitor, or find a firm in the law firms directory.