An interesting topic cropped up on the ISO27k Forum this week. In essence, the issue is whether a small, immature company without an I nformation S ecurity M anagement S ystem could or should have an information security policy. ​ Speaking as an infosec pro, the knee-jerk response is "Yes, of course!". Why do I say that? If SmallCo's CEO or owner asked me to explain, how would I justify my recommendation to have a policy? Hmmm. Tag along or watch from the precipice as I dive into another rabbit warren.

There are information risks associated with people joining any corporate function – information risks that deserve to be identified, assessed, evaluated and treated appropriately like any other. If your organisation currently pays little if any attention to these risks, how about developing and trialling a suitable strategy and approach for, say, the information risk and security management function, as a pilot or demonstrator for other corporate functions and rôles that place a high reliance on the personal integrity of their people?

Whereas ISO/IEC 27001 indicates that only fourteen (14) types of ISMS documentation are strictly required  (mandatory), they are barely a start, even for a barebones ISMS.  In practice,  both mandatory and  discretionary documents are valuable . ISO/IEC 27001 c lause 4.4   states: “The organization shall establish, implement, maintain and continually improve an information security management system, including the processes needed and their interactions, in accordance with the requirements of this document.” Documentation (termed 'documented information' in the standard - see clause 7.5) is generally the best way for management to inform workers about their information security responsibilities  e.g. through written policies, procedures/work instructions and job/role descriptions, accompanied by awareness and training materials such as guidelines and briefings. In addition, many security-related processes generate 'records' such as completed forms, ...

Yesterday I blogged about ISO/IEC 2382 - Information technology - vocabulary . In particular, one of the ~2,000 ISO definitions stood out enough to catch my beady eye: “ Computer-system audit : examination of the procedures used in a data processing system to evaluate their effectiveness and correctness, and to recommend improvements”. Errrr, that covers  some of the audit work I have undertaken, led/managed, been subjected to or heard about in my career* but omits rather a lot e.g. :   IT governance arrangements, strategies, information risk and security management, direction and oversight, structure, integration with other business functions, rôles and responsibilities, accountabilities, reporting lines, assurance, continuous improvement, barriers and progress; Staffing levels and competencies, recruitment and retention, succession planning, contractors and consultants; Security administration, joiners/movers/leavers, culture, awareness and training, accounts/identif...

In the past few days, I have been triggered yet again by someone fearing that ISO/IEC 27001 certification auditors may insist that various Annex A controls are applicable and must therefore be implemented for conformity. Apocryphal nightmares about auditors doing exactly that tend to stoke the fear and prolong the myth. Myth, yes, myth. I've said it before and no doubt I'll say it again: the Annex A information security controls are not formally required for conformity with the standard - none of them, not even one. If you or your auditors believe otherwise, kindly tell us which clause of the standard applies. What are the exact words leading to that conclusion? Spoiler alert: there are none. There is no such requirement. IT DOES NOT EXIST. There is , however, a conformity requirement to check through Annex A for any controls that might reduce otherwise untreated information risks, but even then there is no (repeat, no ) obligation to implement the controls as stated in A...

Someone who is actively involved in, or is managing, an activity is patently not independent of it. They may well make a conscious, rational and determined effort to be objective, dispassionately reviewing evidence etc ., but their subconscious/emotional biases/prejudices and beliefs/value-systems will inevitably influence what they do. With the best will in the world, they will struggle to challenge and assess their past decisions and activities, especially if they were "certain" or "determined" or genuinely believed they were "doing the right thing". Furthermore, it is very hard for anyone to review the things they did not do, decisions they did not make or options they did not even consider. Mostly, they remain out of sight or out of the question.

This checklist is appended to a SecAware guideline on implementing an ISMS , elaborating clause-by-clause on ISO/IEC 27001 - essentially, our version of ISO/IEC 27003 .   It offers  pragmatic guidance for information security managers and CISOs - nothing too obscure or complex. ---oooOOOooo--- Project definition, justification, scoping and planning ⬚   Study the standards, in depth: complete lead implementer training if possible. ⬚   Study the business, in depth, to understand its objectives, strategies, culture, governance arrangements, existing information risk and security management etc . ⬚   If the organisation has a defined, structured approach for this phase, use it! ⬚   Build a business case that identifies and promotes the business benefits of the ISMS. ⬚   Look beyond ‘security’ and ‘compliance’ e.g . helping management to manage business risks, supporting/enabling other business initiatives and strategies.

A thread on the ISO27k Forum sparked my imagination over coffee this morning. Hope had previously asked for assistance with an ISO/IEC 27001:2022 audit plan.  Bhushan offered a lengthy and generally sound response explaining how to use a spreadsheet with tabs to plan and record the audit work performed on 100% of the main body clauses and 50% of the 93 Annex A controls, day-by-day. That's OK ... except it wasn't entirely clear that he was interpreting and elaborating on the standard's actual requirements. ISO/IEC 27001 does not explicitly require, for example, that (as Bhushan stated) "ALL the management system clauses from 4 to 10 AND their sub-clauses need to be listed and audited" in an ISMS internal audit, although evidently he interprets it in that way. In clause 9.2.1, the standard states a requirement for internal audits to provide information on whether the ISMS conforms to the organization’s own requirements for the ISMS plus the requirements of the stan...

ISO/IEC 27001 formally requires just 14 types of "documented information" of  every organisation competently certified conformant with the standard, as a minimum: 1.        ISMS scope (Clause 4.3); 2.        Information security policy (Clause 5.2); 3.        Information security risk assessment procedure (Clause 6.1.2); 4.        Statement of applicability (Clause 6.1.3 d); 5.        Information security risk treatment procedure (Clause 6.1.3); 6.        Information security objectives (Clause 6.2); 7.        Personnel records (Clause 7.2); 8.        ISMS operational information (Clause 8.1); 9.        Risk assessment reports (Clause 8.2); 10.    Risk treatment plan (Clause 8.3); 11. ...

Once again, my day kicked off with a stimulating and fruitful debate on the ISO27k Forum as members responded to a request for help to find accredited I nformation S ecurity Management S ystem certification auditors who will add value to the organisation above and beyond the ISO/IEC 27001 conformity certificate. The original poster copped some grief from the forum in appearing to seek certification auditors who would be kind on the organisation, supporting its business objectives more strongly than its conformity with the standard ... but a follow-up message clarified the position. Aris confirmed to us that he sought:  "advice on where (in cases of an ISO audit) and how (in cases of an Internal audit) our ISMS could/should be improved, but I need that advice to be meaningful, grounded, and delivered in a way that has the best probability it will be absorbed by the business. In other words, I would like this process to offer real value to the business, besides just bein...

ISO/IEC 27001 is a succinct, formally-worded standard for two key reasons: It is deliberately generic, being applicable to all manner of organisations regardless of difference in location/s, size, industry, maturity, structure, information risk and security status ... and so on. In effect, it specifies the lowest common denominator - the things that ALL organisations should be doing to manage their information security controls, as a minimum. The hurdle is set low enough that every organisation ought to find value in designing, implementing and operating an I nformation S ecurity M anagement S ystem as laid out in the standard. It is a certifiable standard, explicitly specifying the characteristics that every certified organisation's ISMS is expected to have. Again, it is a minimal specification with no concept of typical, average or maximum security: that is entirely down to the organisations themselves to determine, following the information risk management processes minimally de...

Finding weaknesses/concerns and improvement opportunities in the organisation's information risk, security and related arrangements is a valid and potentially valuable outcome of an ISO/IEC 27001 certification audit. Arguably, however, that is what the management reviews and internal audits are supposed to achieve.   Certification auditing is primarily intended to provide assurance for the organisation and third parties that the organisation has correctly interpreted and implemented the standard, a specific key objective. One way to resolve this conundrum is for certification auditors to distinguish: " Major nonconformities " - demonstrable and substantial failures to fulfil any of the mandatory requirements of 27001; from " Minor nonconformities " - insubstantial failures and/or failures against the discretionary requirements of 27001; and  " Observations " - anything else noted in the audit that the auditor believes is worth bringing to management...

Over on the ISO27k Forum  this week, Ray asked us for  "guidance on conducting and documenting 'Management Reviews' that include the agenda items required by the standard in 9.3. Any templates shall be much appreciated."  Forumites duly offered advice and agendas. So far so good! However, I made the point that  ISO/IEC 27001 does not require/insist that management reviews take the form of periodic management meetings, specifically, although that is the usual approach in practice.  Personally, since they are both forms of assurance, I advise clients to plan and conduct their ISMS management reviews and ISMS internal audits similarly, with one critical and non-negotiable difference: auditors   must  be independent of the ISMS, whereas management reviews   can  be conducted by those directly involved in designing, operating or managing the ISMS. This is not merely a compliance matter or protectionist barrier: auditor independence bri...

This morning,  a new member of the ISO27k Forum asked us some questions about his organisation's upcoming ISO/IEC 27001 certification audit (paraphrased below).  Since these are commonplace issues, I address them here on SecAware blog for the benefit of others in the same situation now ... or at earlier stages.  Management being ready for the certification audit has implications for the way an ISO/IEC 27001 I nformation S ecurity M anagement S ystem was originally initiated/conceived, scoped, planned and approved, as well as how it is managed once it comes into operation. 1. Does the auditor need to talk to the CEO or would another member of Top Management such as the COO or a VP be sufficient? That is for the auditor to decide. CEOs are invariably busy people ... but the CEO's non-involvement (even before being asked!) hints  at a lack of support or engagement from senior management*. If other senior managers are more willing and able to be interviewed, that ...

As anticipated, the I nternational A ccreditation F orum has published updated guidance on the transition arrangements for certification of organisations against ISO/IEC 27001:2022 , the new third edition of the standard released in October . There are several possibilities under various circumstances (as I understand it*) ... 1) Organisations that are already certified to ISO/IEC 27001:2013 (or to equivalent national translations of that old 2013 edition of the standard) have about three years to move to the  new 2022 edition . Meanwhile, surveillance audits can use either edition of the standard, whichever the organisation chooses to use. 2) Organisations currently preparing to be certified prior to June 2023 can choose either edition:

While waiting impatiently for today's stormy NZ weather to subside so I can get outside and survey the damage, I spent a productive few hours writing-up a pair of recent consultancy assignments as case studies for  the SecAware website . < The first case study concerns helping a US tech support company to regain its ISO 27001 certification by rebuilding its failed ISMS. Officially, the assignment was simply an ISMS internal audit. In practice, it involved some lightweight mentoring and support for a capable CISO. T he second case study concerns consultancy support for a 6-month ISMS implementation project for an innovative NZ agritech company > Again, although the centrepiece of the assignment was an ISMS management review, it involved gently mentoring and guiding the project managers (two contractors) and providing assurance for the client's senior management - plus stress-reduction when both contractors departed shortly before certification.

A new member of the ISO27k Forum asked how long they have to resolve a minor nonconformity reported by the certification auditors. I didn't know the answer so I looked it up in  ISO/IEC 27006 . Clause 9.6.3.1 says (in part): "The time allowed to implement corrective action shall be consistent with the severity of the nonconformity and the associated information security risk."  Significant risks should be addressed as a priority, whereas minor risks may be addressed 'in due course', perhaps as part of other planned changes or when the opportunity arises. Furthermore, complex  issues are bound to take some time to resolve, whereas  simple  things may be resolved more or less on the spot.  I suggested the reported nonconformity should be addressed in the normal way, using the organisation's documented ISMS processes along these lines:

Other than the classic "Show me", here are a bunch of generic questions to consider, select and refine if you are conducting an ISMS internal audit, IT audit, ISMS management review etc. looking into 'X' (an ISMS, situation, system, process, control, incident or whatever). Hopefully these are thought-provoking, helping you consider and explore X from different perspectives.  Are there any legal, regulatory or contractual compliance implications of X? Are there any other things about X that I/management should know about? Can I do some audit tests on X, please? Compared to Y and Z, how risky/valuable/reliable is X? Does anything strike you as strange or worrying about X? Explain the controls relating to X … Has X ever hurt anyone? What happened? Have you or anyone else raised concerns about X? How big is X - how wide, how heavy, how numerous, how often? How come previous efforts did not fix X? How costly was X?

SEE UPDATE 19th Feb 2023 The third edition of ISO/IEC 27001 will have a few changes in the main body text and a complete replacement for Annex A based on  ISO/IEC 27002:2022 .     The transition arrangements are still uncertain but this is my understanding at this point:

... "a structured assurance process of examination, review, assessment, testing and reporting by one or more competent and trusted people who – crucially – are independent of the subject area being audited" [source:  SecAware glossary ] ... senior management's not-so-secret weapon ... how to use friends and influence people ... how to lose friends and alienate people ... proof that management distrusts us ... where failed accountants go to die ... seeing things through fresh eyes ... a massive and unnecessary cost ... "Go ahead punk, make my day" ... derived from the Latin audio ... forever re-opening old sores ... like a bear with a sore head ... the skin-hardening function ... watching your every move ... dependent on information ... bayonetting the wounded ... the bottom of the barrel ... the third line of defence ... something best avoided ... always late to the party ... policies and procedures ... asking dumb questions ... lurking in the shadows ... a gove...