statement of applicability.
understanding what the statement of a click ability is
understanding its components and wider such an important artifact in I So 27,001, Specifically, foreign eyes mess
and understanding what needs to be included in the S o a document.
This could be one of the most time consuming documents to put together and maintain.
So what is the statement of applicability, which is also known as the S O. A document
the S O A. Indicates which controls are in and out of scope.
When they control framework is selected to support the ice amiss,
it must be noted that not all controls within a pre defined framework such as I so 27,002
on mandatory for implementation.
A large determination off controls comes from the risk profile of your organization,
the needs and expectations of interested parties.
Whether a control is a legal requirement
or whether it is based on a contract your obligation with an external stakeholder,
each control that is listed within an adopted framework such as I said 27,002
must be included in the statement of applicability and an indication provided whether this is applicable to the scope or not,
as well as why the control has been included or excluded.
The justification for inclusion can be simplistic,
while the justification for control exclusion must be sufficient and valid,
either showing it is not applicable in the operating context of the organization
or that the risk is not present due to whatever reason
the controls listed in a pre defined framework such as I So 27,000 and two
the ice f standard of good practice and so forth are not exhaustive in nature. For your s o A.
The S O A. Should also include any controls which the organization has or will implement, that are unique to the organization and which is not directly covered in one of the other controls.
If you're feeling a bit last as to wear and how this fits into the icy mess,
don't worry, it will make more sense as we go through the course.
The reason for including the statement of applicability so early on in the
this document is literally one of the most important documents in your entire Isom s.
So it deserves a segment on its own.
The statement of applicability. Defiance. See controls that you will implement to support your ice, Miss
it basically states which controls are
part of your eyes, miss and which are not part of your eyes, Miss, and why,
when we go through Clauses six and eight for risk management,
this will make a lot more sense.
As you mentioned previously
on your statement of applicability. You will need to provide a justification for each control as to why it is either included or excluded.
This could be quite a lot of work when you consider that the I. So 27,000 and two
also known as an extra a body of controls,
consists of 114 controls,
not including your own custom controls.
So that's quite a lot of work to go through each one of these controls and determine
is this applicable to your organization? Isn't it applicable and why? For each of those
for controls that are included, the reasoning will relate to how this control serves to mitigate or modify a specific risk or multiple risks.
This will tie back into your risk assessments so ensure that there is consistency between the two.
It could be extra hopeful to include explicit references between your statement of applicability and risk register
so that mitigating controls and the risk bridges that link to specific controls in your statement of applicability
in your statement of applicability controls contain the specific numbers or whatever identify you want to use for risks in the risk register.
In other words, your statement of applicability and risk register cross reference each other.
There is no point, including controls or trying to implement controls that are not going to serve any purpose,
and we'll just end up incurring additional time and cost. Resource is,
it is perfectly OK to exclude certain controls from your statement of applicability
as long as the justification is sufficient.
controls that pertain to outsource development might not be applicable to your organization.
If you do not use an outsourced
software development provider,
use the access controls are probably applicable to your organization, and excluding those would probably not going down that well with an auditor
unless you have some very good reason as to why they are not applicable.
To give you an example off. What
a statement of applicability layout looks like. This is a simple table to give you a general idea. Yuk undocumented this in whatever you want.
Generally, it's done in an Excel sheet or somewhat at the table format,
as it is the easiest way to maintain the data and include the references that you need.
What you need to do is list all the controls in the controls framework you are adopting, whether it's 27,002, nursed whatever you're using, as well as any custom controls that your organization may have.
You can also include additional columns in your statement of applicability that make it easier to manage within the organization.
If, for example, you have specific personnel responsible for certain controls,
you could list that here to demonstrate ownership and how many people are involved in the ice and this controls.
You can also link the controls to any project plans or risk treatments that are currently ongoing
to indicate that tracking on these is being performed.
So as you can see from this example,
it's based to include a control number or some sort of reference to the control.
If you're using a pre defined framework. These will generally come with a pre configured or established control number.
The control, objective and description is useful to
show what purposely control is serving in the organization
indicate whether or not the control is included or excluded in your scope.
For each inclusion or exclusion,
a justification should be present
when they control needs to be included.
There will be some or other risk that it is mitigating.
It is up to you how to just yet.
Excuse me, document the justification.
You can either write this out in your own words.
All right, it out in your own words,
including a reference to your risk
that it is mitigating
or simply linked to your risk register and the corresponding risk.
Another important components include is the current status of the control.
Not all controls will be at this at the same level, meaning some controls may be fully implemented, while others are only partially implemented or not implemented at all.
Providing mawr quantitative
determination, off control status,
for example, a control that is partially completed
to 80% versus a control that is partially completed to 30%
is quite a big difference.
so if you have that information available, rather included and provide
but it will definitely help you if you go through a certification ordered
In this lesson, we covered what the statement of applicability is
and what it is used for in your items.
Why controls need to have justifications both for being included as well as excluded.
We also took a brief look at a simple statement of applique ability, layout
and the minimum required components that should be included
again. This is one of the most important pieces of documentation that will come out of your eyes amiss.
It is loosely tied to close 6.1 point three,
and that is where the
statement of applicability will most likely come out from. Once you have done your initial risk assessment and determined your risk treatments.