Control 5.9 in ISO/IEC 27002:2022 recommends an inventory of information assets that should be “accurate, up to date, consistent and aligned with other inventories”.    Fair enough, but what are ' information assets'? What, exactly, are we supposed to be inventorying?   The standard refers repeatedly but enigmatically to "information and other associated assets" that an organisation’s I nformation S ecurity M anagement S ystem protects. The intended meaning of 'information asset' has been a bone of contention within ISO/IEC JTC 1/SC 27 for years , some experts and national bodies vehemently disagreeing with each other until, eventually, a fragile ceasefire was declared in order to move forward on the numerous standards projects that hinge on the term.    Currently, '27002 provides a rather broad and unhelpful definition of "asset" as "anything that has value to the organisation" - paperclips, for instance, fall within the definition. D...

Although the organisational/business context is clearly relevant and important to information risk and security management, it is tricky to describe.  In my opinion, clause 4 of ISO/IEC 27001 is so succinct that it leaves readers perplexed as to what 'context' even means.  It stops short of explaining how to determine and make use of various 'internal and external issues' in an I nformation S ecurity M anagement S ystem.  So, to help clients, I wrote and released a pragmatic 5-page management guideline on this for the SecAware ISMS toolkit , expanding on this neat little summary diagram: With about a thousand words of explanation and pragmatic advice, the guideline has roughly ten times as many words as clauses 4.1 and 4.2 ... or twenty times if you accept that the picture is worth a thousand words. It was written independently of, and complements, ISO/IEC 27003 's advice in this area. Although I am happy with the SecAware ISMS toolkit materials as they are, I...

  For some curious reason, the S tatement o f A pplicability steals the limelight in the ISO27k world, despite being little more than a formality. Having recently blogged about the dreaded SoA, 'nuff said on that. Today I'm picking up on the SoA 's shy little brother, the  R isk T reatment P lan. There's a lot to say and think about here, so coffee-up, settle-down, sit forward and zone-in. ISO/IEC 27001 barely even acknowledges the RTP . Here are the first two mentions, tucked discreetly under clause 6.1.3:

Thinking about the principles underpinning information risk and security, here's a tidy little stack of 44 "Hinson tips" - one-liners to set the old brain cells working this chilly mid-Winter morning: Address information confidentiality, integrity and availability, broadly Address internal and external threats, both deliberate and accidental/natural Celebrate security wins: they are rare and valuable Complete security is unattainable, an oxymoron

The SecAware corporate information security policy template incorporates a set of generic principles for information risk and security such as " Our Information Security Management System conforms to generally accepted good security practices as described in the ISO/IEC 27000-series information security standards. " and " Information is a valuable business asset that must be protected against inappropriate activities or harm, yet exploited appropriately for the benefit of the organization. " Despite being reasonably happy with the 7 principles I selected, I would prefer to base the policy on a generally-accepted set of infosec principles, akin to the OECD Privacy Principles first published with remarkable foresight way back in 1980 .      There are in fact several different sets of principles Out There, often incomplete and imprecisely stated.   Different authors take different perspectives, emphasizing different aspects, and the contexts and purposes als...

Inspired by an insightful comment on LinkeDin from an SC 27 colleague on the other side of the world (thanks Lars!), I spent most of last week updating the SecAware security policy templates and ISO27k ISMS materials . The main change was to distinguish conformity from compliance - two similar terms that I admit I had been using loosely and often incorrectly for far too long. As I now understand them: Compliance refers to fulfilling binding (mandatory) legal, regulatory and contractual obligations; Conformity concerns fulfilling optional (discretionary) requirements in standards, agreements, codes of ethics etc.   It's a fine distinction with implications for the associated information risks, given differing impacts: Noncompliance may lead to legal enforcement action (fines/penalties), other costly sanctions (such as more intrusive monitoring by the authorities and perhaps revocation of operating licenses) and business issues (such as reputational damage and brand devaluation, p...

To celebrate the publication of ISO/IEC 27400:2022 today, we have slashed the price for our IoT security policy templates to just $10 each through SecAware.com. IoT policy is the first of the basic security controls shown on the 'risk-control spectrum' diagram above, and is Control-01 in the new standard ... Do you have a security policy on IoT? If not, does that mean IoT is out of control in your organisation? Even if you do, what does it say? Is it valid, appropriate, worthwhile, sufficient?   The spectrum diagram shows quite a variety of risks and controls, but it is merely a summary, selected highlights. Attempting to cover them all in a policy document would be counterproductive - in fact, general employees can barely cope with a much-simplified one-page 'acceptable use policy'.   The new ISO/IEC 27400 standard takes a broad perspective with copious advice on information security and privacy for the designers, manufacturers, purchasers, users and administrators o...

Subclause 6.1.3 of ISO/IEC 27001:2013 requires organisations to define and apply an information security risk treatment process to: a) select appropriate information security risk treatment options, taking account of the risk assessment results; The 'risk treatment options' (including the information security controls) must be 'appropriate' and must 'take account of ' (clearly relate to) the 'risk assessment results'. The organisation cannot adopt a generic suite of information security controls simply on the basis that they have been recommended or suggested by someone - not even if they are noted in Annex A. b) determine all controls that are necessary to implement the information security risk treatment option(s) chosen; NOTE Organizations can design controls as required, or identify them from any source.