After my latest ISO 27001 audits, I see the same mistake.
Companies that declare applicable controls that have nothing to do with their reality. They complicate their lives, waste time and spend money unnecessarily.
In the worst case, a financial services firm with no developers and no lines of code imposed all the standard controls on itself. Their consultant had convinced them that “it was safer this way”.
If your company doesn’t develop software, some of the controls in ISO 27001:2022 won’t apply to you.
In my audits, I find that 70% of non-developing companies declare that they still apply controls that they have no business implementing. There are three reasons for this:
First reason: Their consultant is afraid. They’d rather say “applicable” than justify why it’s not. Easier to bill overtime than to explain the logic behind a declaration of non-applicability.
Second reason: Management thinks “stricter” is better. No. It’s just more expensive and more complicated for nothing.
Third reason: Nobody took the time to really understand what the company actually does. A generic “template” is applied instead of analyzing the specific context.
The following controls are not applicable
When your company doesn’t do any software development, these five controls don’t apply:
A8.4 – Access to source code, clearly if we have no development, there’s no source code to manage!
A.8.25 – Secure development lifecycle If you don’t have a development team, you don’t have a development lifecycle.
A.8.26 – Application security requirements This control concerns the security specifications for your own applications. Not those you buy or rent. If you don’t develop anything, this control doesn’t concern you.
A.8.27 – Secure architecture and engineering principles This covers the secure design of the systems you develop. Once again, without development, there is no architecture to design.
A.8.28 – Secure coding The most obvious. No code, no secure coding. Some companies think that configuring software is “coding”. No, it’s configuration.
A.8.29 – Security tests in development Security tests on code under development. Without development, this control falls through.
The grey areas that create confusion
Three controls often create confusion:
A.8.30 – Outsourced development This one is more subtle. If you hire outside programmers to develop something specifically for you, this control applies. But if you buy software off the shelf, even if it’s customized, it doesn’t count as outsourced development.
A.8.31 – Separation of environments You don’t need a development environment if you don’t develop. However, if you have a test environment for your purchased software, this control may be partially applicable.
A.8.33 – Test information If you never test anything, this check doesn’t apply. But beware: most companies do at least acceptance testing on their new software.
What remains applicable
Control 8.32 – Change management is almost always applicable, even without development. Because you’re changing configurations, updating software, modifying settings. That’s change management.
For other controls, such as network security, access management, backup, training? They remain applicable, because with or without development, these measures protect your IT environment, no matter where your software comes from.
How to assess applicability
Ask yourself these simple questions:
- Does anyone in my company write code?
- Do we have in-house programmers?
- Do we hire firms to develop applications specifically for us?
- Do we modify our software source code?
If all answers are “no”, then checks A8.4, 8.25 to 8.29 do not apply to you.
Justification is mandatory
When you declare a control inapplicable, you must justify it in writing in your Declaration of Applicability. This is not optional, it’s a requirement of the standard.
A good justification looks like this:
“The company does not develop any software in-house, nor does it use any development suppliers. All software used is a commercial solution acquired on the market..”
Beware of changes
Your declaration of applicability is not set in stone. If your company evolves and starts to develop, you’ll need to revise this declaration.
I’ve seen companies that started by buying software, then hired programmers to customize it. Overnight, certain controls became applicable again.
I invite you to click on “Follow” to continue learning more about information security and privacy topics.
