Alan Field explores the links between quality management and information security, looking in particular at International Organization for Standardization (ISO) 9001:2015 and ISO 27001:2013.
Information security and quality management are often seen as separate disciplines.
However, the way business is done is, of course, continually changing and this means that organisations need to be aware of how quality management issues are directly impacted by information security considerations. The changing regulatory requirements — such as the General Data Protection Regulation (GDPR) — makes this an even more significant consideration.
This article explains some essential links between quality management and the information security elements increasingly inherent within them.
While there are various audited and non-audited approaches, this article will be chiefly based on ISO 9001:2015 (for quality management) and ISO 27001:2013 (for information security management). Both follow ISO’s “Annex SL” document; this outlines how all assessable management systems (which includes ISO 9001 and ISO 27001) should follow a leadership and risk-based model.
It also means that if an organisation wants to integrate or combine some elements of their ISO 9001 and ISO 27001 systems together, then there is already an element of compatibility provided by the Annexe SL structure both standards have to follow.
Quality Management Systems (QMS) are, typically, customer focused. Those that follow ISO 9001 requirements will always be so.
In broad terms, the QMS exists to ensure promises to the customer can be met in a consistent way. This cannot be done if the terms of the agreement (usually a contract or series of contracts) are not fully understood by all those delivering the product or service.
For example, do all staff understand what has been agreed with a customer in terms of security of data shared or processed through them — be this the customer’s documents, intellectual property or banking information? If the answer is no, then this may — at the least — be creating an unnecessary risk that should be addressed by better internal communication and/or process design. After all, ISO 9001:2015 is a risk-based standard.
The notion of contract review — or determination of customer requirements — is the cornerstone of almost any QMS. The term “customer” includes those better described as clients and those parties whom as part of the customer’s requirements are treated as such by the principal, eg in a project management contract there may be agreements to make deliverables to other design partners who are neither contractors nor suppliers. In other words, there is no control — and no choice — but to deal with them. There can be complex issues involving, say, sharing intellectual property unless the contract does create framework or obligations to respect these.
Many organisations have standard terms and conditions upon which they do business. These may have various expectations about document control, confidentiality and, sometimes, minimum requirements as to data security. These need to be understood by all staff so they can flag to their line management if customers, suppliers or other partners to the contract are apparently breaching them, deliberately or, more likely, simply though having inadequate systems or consistent controls to consistently deliver them.
Remember contracts are signed by senior people who may not fully understood the processes of their organisation at a day-to-day operational level. As with risk management generally, never assume the other parties are better than yourselves at managing risk. They may well not be. Second, there is often not much if any, sharing of approaches to data security between the different contractual parties in terms of understanding one another Information Security Management System (ISMS) and countermeasures deployed.
For example, in one actual case, there was a significant data breach in the USA arising from a contractor’s IT system which had legitimate access to the IT systems of their principal. The contractor suffered a cyberattack which, in turn, provided a backdoor into their principal’s IT system for the cyber criminals concerned. The criminals then remotely harvested significant amounts of customer data — including electronic payment card details — from the principal’s system.
An ISMS will usually consider contractual obligations and other legal protections that assist information security. However, contracts only give an organisation the right to sue. Contracts are not a physical protection in themselves but they can encourage other parties to look at controls and countermeasures more closely.
The other side of the coin for a QMS is where a customer requires confidentiality or other data controls over and above those outlined in the standard terms and conditions. As well as legal review of any such conditions, the quality and information security specialists within an organisation should be consulted to see if current systems can meet these proposed obligations.
Alas, in the author’s experience this is not always done, and obligations are accepted without fully considering whether they can be delivered, ie being able to provide, in a cost-effective way in relation to the contract value and profit margin, that accidental or deliberate disclosure of data is highly unlikely to arise. Remember what is sensitive to one organisation may not always be so to another, ie the QMS may treat some aspects of customer property more seriously than others in terms of process controls. Would the customers agree, even if their concerns might seem disproportionate?
No deal is too good to risk the organisation’s reputation and data security and expose them to financial risk unless, of course, top management feels the obligations being accepted can be adequately controlled. This is rarely just a legal question but does need the input from those who run the quality and information security to see what is achievable and what, currently, is not.
Annexe SL talks much about leadership and risk management, and information security is part of the decision making on all contract review issues, even if a formal ISMS is not in place.
New red tape?
The changing regulatory environment is compounding this drive of quality becoming more aligned to information security. For example, on 25 May 2018 the EU GDPR is scheduled to come into force. The Information Commissioner’s Office reported that the Government has confirmed that the UK’s decision to leave the EU will not impact on the commencement of the GDPR.
The GDPR applies to all “controllers” and “processors” of data, with certain exceptions. While this broadly follows the principles of the current Data Protection Act, there will be some new specific legal duties. The penalties for non-compliance will be considerably higher. The GDPR has some more explicit requirement, eg the right to review of automated decisions (ie where computer algorithms decide, eg the route a delivery vehicle will take on the day or, say, an automated financial decision relating to a loan).
In short, GDPR will not only impact on document and data control but, for some organisations, processes generally and customer services in particular, will need some changes to be made. Also, countermeasures against data being compromised may need strengthening in some cases. So, this could be taken as an opportunity for leadership teams to ensure there is more co-operation between, if not integration of, QMS and ISMS functions.
An ISMS often requires some element of specialist IT input to be successfully implemented. However, this does not imply that an ISMS is somehow separate from a QMS. In fact, many a QMS will, progressively, have a number of quite specific vulnerabilities to data protection and contractual obligations relating to confidentiality. These need to be recognised as risks that need to be managed.
Even if no level of integration between the ISMS and QMS is anticipated, the distinctions between an information security risk and a risk to the quality objectives should be evaluated. Once this is done by each organisation, the areas of communality between quality and information security risks in each area can then be understood and implemented.
Last reviewed 12 February 2018