Not quite old news: Statement of Applicability

[GKWvfr]

Hi Guys n Girls,

I'm in a small business (15-30) employees in a very low risk business environment, and reviewing our ISO 27001 Management System and have spent most of the day scratching around the internet for sample SOA's etc.

Having found a few, they vary in size and amount of information, so I'm trying to get some ideas/feedback on how minimal I could keep it and keep our BSI Auditor happy. (I have approached them, and await their feedback) , but thought I'd tap this resource a bit too.

I'M thinking of streamlining both our SOA and Risk Assessment against 27001 assets, but the SOA i think can be a lot smaller than current one (I had to print it onto A1 paper to be able to read it all on one sheet.

Could I get away with a small SOA, that simply has columns for

Column A: Control # and name (According to annex A of ISO 27001)
Column B:Whether it is applicable or not
Column C: Exclusion justification where needed
Column D: Basic details of how that control is applied

So the above columns could be populated such as

Column A: 8.1.2:Screening
Column B: Yes
Column C: N/A
Column D: HR dept process application details and investigate applicants history

On the risk assessment side of things, i would list in the "human Asset" table that control 8.1.2 is applied at application stage to ensure we employ the right kind of person

Any thoughts muchos gracias

Greg

 

[pldey42]

You need justification for inclusion as well (ISO 27001:2013 6.1.3.d) which could be a pointer to the risk assessment or treatment plan that called for it.

You could consider an extra column or two (not mandatory in the standard but perhaps helpful) that indicates whether a control's effectiveness is measured and if so, the target and the current value or trend.

Do keep in mind that any you find on the internet are likely to have been sanitized such as not to expose lack of controls that the company would like but, e.g. can't afford. There may also be controls in use that aren't declared in public to make them harder for an attacker to defeat.

There was a time when the SoA was regarded as a public document, but since that was clearly crazy, it's no longer seen that way. But that's the reason that sometimes you can find an SoA on the internet: the teaching then was, make a private real one and a public sanitized one; the public one was of course as useful as a chocolate padlock. I would never publish an SoA, seeing no reason to help attackers perhaps unwittingly. I would share it with clients on request under an appropriate NDA, maybe after a risk assessment and sometimes sanitized for our mutual protection.

Hope this helps
Pat

 

[infosaas]

Ahhh - the good old SOA! I've lost count of how many times I have been asked to share this, but when you discuss why a customer/consultant/etc needs it it is often far simpler to share just the controls which have not been selected by your organisation! I personally believe that an SOA without the context of the risk assessment and control implementation activities is of limited value (at best) to a third party.

Having said that, an SOA in my experience is a table which chronicles which controls has been selected by each asset during its regular risk assessment. This can be a time consuming exercise - my colleague used to spend two days each year preparing this - which is one of the reasons why I created InfoSaaS where the SOA is automatically populated as each risk assessment is completed and finalised.

 

[GKWvfr]

Thanks for your input folks.

My new SOA went live for our transition audit to 27001: 2013 and passed the scrutiny.

I finished with columns as below in case anyone in a similarly low risk environment like mine needs one

control number
control name
control requirement
adopted/excluded
reason for adoption/exclusion
implemented (y/n)
manifestation of control
and a final column for comments

thanks for your help guys