There are clearly substantial information risks associated with the redaction of sensitive elements from disclosed reports and other formats, risks that the controls don't necessarily fully mitigate. Yes, controls are fallible and constrained, leaving residual risks. This is hardly Earth-shattering news to any competent professional or enlightened infidel, and yet others are frequently shocked.  A new report* from a research team at the University of Illinois specifically concerns failures in the redaction processes and tools applied to  PDF documents . The physical size of redacted text denoted (covered or replaced) with a variable-length black rectangle may give clues as to the original content, while historically a disappointing number of redaction attempts have failed to prevent the original information being recovered simply by removing the cover images or selecting then pasting the underlying text. Doh!

... a cluster of international standards on information security management and related topics ... derived from British Standard BS 7799, itself based on an information   security  manual generously donated to the UK government's Department of Trade and Industry by the fuel company Shell International ... the product of  ISO/IEC Joint Technical Committee 1 SubCommittee 27

Having done, seen and learnt a lot in the course of working with the ISO27k standards and precursors since the mid-90's, I'm keen to share my accumulated knowledge with those of you who are relatively new to the field, just setting out and perhaps struggling to get to grips with it all. You needn't learn everything the hard way like I did: I can help you move ahead smartly, avoiding tar pits, finding taller ladders and shorter snakes.

Like ambient music (muzak, elevator tunes), ambient information security blends into the background.  The idea is that infosec controls are subtle, seamless, integral parts of whatever is going on, as opposed to blatant in-yer-face shouty SECURITY. Of course it's not always possible, and there are circumstances where the visibility of security is itself a valuable part of the controls - deterrents, for example, warning signs, distinct boundaries and the menacing presence of beefy security guards, with guns, dogs and attitude.   Personal identification and authentication processes that require user interaction are hard to miss e.g. security passes/tokens, passwords, PIN codes, SMS codes and all that rigmarole. Nevertheless, there are choices for system/security architects when designing login mechanisms that affect the amount of time and effort required from each user.   Those are the exceptions. A majority of security controls go largely unnoticed. Federate...

Prompted by a random podcast comment and inspired by a productive day in the garden, here's an analogy between governance and gardening. 

... "s trategic frameworks, organisational structures, policies and processes used to guide/direct, oversee/monitor and to some extent control the organisation, ensuring that it fulfils its strategic objectives and complies with internal and external obligations" [source:  SecAware glossary ] ... applicable to corporations, organisations, nations, the globe, industries, business units, finance, the environment, governments, projects, land, health, steam engines, watches, IT, information , information risk and security ... ... for the benefit of stakeholders, owners, regulators, authorities, society ... designing and implementing appropriate corporate structures

'6.3 Planning of changes' is a succinct new clause in ISO/IEC 27001:2022, one accidentally omitted from the contents listing (oops). Simply put, changes to the Information Security Management System must be planned, rather than simply happening haphazardly. What kinds of ISMS changes would this cover? Without further clarification, it could be argued that any and every change to the ISMS has to be "carried out in a planned manner", begging further questions about the intended purpose and scope of the clause, and of the ISMS itself.  If we add a new topic-specific information security policy on IoT, for instance, or update the risks list, would such changes need to be planned? How about simply renaming the organisation's list of risks to, say, Information Risk Register - should that be planned? Would correcting a little typo in an ISMS procedure or awareness item count as an ISMS change that has to be planned? 

... "adverse change to the level of business  objectives achieved" [source:  ISO/IEC 27000 ] ... the inertial energy imparted by a moving mass impinging upon an object ... "t he adverse outcome or consequences caused by or arising from an information security incident , leading to direct and/or indirect (consequential) losses/costs to the organisations and/or the individuals concerned" [source:  SecAware glossary ] ... the point when probability functions collapse ... when possibility becomes reality ... when threat meets vulnerability ... short, medium and long-term ... loss of control over an asset ... too late to prevent or avoid ... being smacked in the head ... when p (occurrence) hits 1 ... when gloved fist hits chin ... what we tried to prevent ... what we sought to avoid ... an impressive entrance ... the resonance of a bell ... when risk eventuates ... when shit meets fan ... not too late to react ... being compromised ... a successful attack ... the p...

... " an inherent and potentially exploitable weakness in an information asset, system, process, organisation etc."   [source:  SecAware glossary ] ... exposed by one or more missing, ineffective or inadequate  controls ... “a security weakness in a computer” [source:  NIST SP800-114 rev1 ] ... “a weakness, susceptibility or flaw of an asset or control that can  be exploited by one or more threats” [source: Financial Stability Board  Cyber Lexicon ] ... "weakness of an asset or  control  that can be exploited by one or more  threats ”  [source:  ISO/IEC 27000 ] ... "weakness in a system, system security procedures, internal controls, or implementation that could be exploited or triggered by a threat" [source:  NIST SP 1800-17b ] ... a chink in the armour ... a gap in our defences ... revealed in incidents ... asking for trouble ... taking a chance ... misplaced trust ... the wea...

Given research indicating that security culture trumps security policies , how can we strengthen the corporate security culture? Here are a few ideas to set you thinking:

A note on LinkeDin led me to an intriguing scientific research study that tested the following five hypotheses: People who receive instructions via a written policy about rules will have better knowledge of these rules than those that do not.  People who receive a shorter form version of policy about the rules with less text will have better knowledge of the rules than those who receive a longer training form.  People who receive a written policy outlining the rules in a more vernacular and less legal technical language will have better knowledge of the rules than those presented with a more formal-legal-styled training text.  People with better knowledge of rules will also comply more with such rules. The more legal rules align with people’s personal and social norms, the higher people score in their knowledge of these legal rules.