The final topic-specific policy example from ISO/IEC 27002:2022 is another potential nightmare for the naïve and inexperienced policy author.
Even if the scope of the policy is constrained to the IT context, the information security controls potentially required in, say, software development are many and varied, just as the development and associated methods are many and varied, and more poignantly so are the information risks.
Your homework challenge, today, is to consider, compare and contrast these five markedly different IT development scenarios:
- Commercial firmware being developed for a small smart actuator/sensor device (a thing) destined to be physically embedded in the pneumatic braking system of commercial vehicles such as trucks and coaches, by a specialist OEM supplier selected on the basis of lowest price.
- A long-overdue technical update and refresh for a German bank's mature financial management application, developed over a decade ago by a team of contractors long since dispersed or retired, based on an obsolete database, with fragmentary documentation in broken English and substantial compliance implications, being conducted by a large software house based entirely in India.
- A cloud-based TV program scheduling system for a global broadcaster, to be delivered iteratively over the next two years by a small team of contractors under the management of a consultancy firm for a client that freely admits it barely understands phase 1 and essentially has no idea what might be required next, or when.
- A departmental spreadsheet for time recording by home workers, so their time can be tracked and recharged to clients, and their productivity can be monitored by management.
- Custom hardware, firmware and autonomous software required for a scientific exploration of the Marianas trench - to be deployed in the only two deep-sea drones in existence that are physically capable of delivering and recovering the payload at the extreme depths required.
- The need for information security and quality assurance controls to
protect both the development and acquisition process and the associated
- The activities necessary to identify and take due account of information security requirements for the IT system, application, or indeed information service being developed or acquired.
Preparing a policy, however fantastic it may be, is necessary but not sufficient. There's more to do. What does it mean, in fact, to 'implement' a policy? Policy implementation may involve:
- Making those who are affected by the policy, particularly those who are expected to do or not do certain things to comply with it, aware of the expectations or obligations, perhaps training, encouraging and supporting them to act accordingly.
- Preparing procedures and guidance amplifying and explaining the policy in more practical terms, translating management's formal direction into plain language that makes sense in the operational business context e.g.
- How should workers 'keep up to date with security patches'?
- Why is it necessary? It's reasonable for workers to question why they have to do anything different, and ask what's in it for them.
- What - if anything - do they need to do, or not do?
- When should things happen, checking for updates for instance? Are there to be regular activities, proactive or reactive things, both, or something else?
- Who is expected to comply with the policy? What about the assurance aspects such as checking/measuring, reporting and achieving adequate compliance?
- Who is expected to own and maintain the policy and associated procedures etc. Also how and when?
- Adjusting existing working practices both directly and indirectly affected by the policy, emphasising any important control elements (such as the appropriate people being informed when security-related patches are released, promptly patching high priority servers) and if possible integrating other aspects through more subtle adjustments (e.g. casually mentioning security patching as an example during worker orientation training).
- Putting in place complementary/supporting controls, not least those specified in the policy e.g. patch management systems, identification and quarantining of unpatched systems, patch testing for BYOD and corporate systems, patch delivery and follow-up ...).
- Operating the policy routinely, gradually becoming part of business-as-usual (hopefully! If it doesn't, it clearly isn't working as intended, suggesting the need to review and revise).
- Providing compliance incentives or rewards, supplementing noncompliance penalties. This can be a surprisingly motivational approach - perhaps something as simple as a few words of encouragement and thanks to people or teams that make a genuine effort to comply.
- Building on, strengthening or supplementing the policy where appropriate, in the light of experience, as the policy and related processes and controls mature.
- Updating the policy as things change, including cross-references to other relevant policies and procedures.
There's clearly quite a lot to do beyond drafting and approving the policy itself. I guess you could develop a policy about implementing policies (!), but more useful might be a generic procedure or checklist reminding people of what should happen - perhaps something simple along the lines of the bullet points above. It needn't even be documented as such, provided those involved know what needs to be done and do it, routinely, reliably, efficiently and effectively: would further documentation and control add net value i.e. deliver business benefits exceeding the associated costs of yet more red tape? If so, go ahead. If not, well you've reached the end of the line and there are almost certainly more important things to do.