Cyber Incident Readiness Assessment (derived from ISO27035:20

SP800-61)

<organisation name>
Scottish Government
St Andrew's House, 2 Regent Road, Edinburgh EH1 3DG

Prepared By:
Name:
Phone:
E-mail:

Document Version Control

Document Classification:
Client:
Document Reference:
Author Name:
Technical Approval:
Document History
Issue Number Issue Date Issued By
1 1/19/2020 SG CRU

Document Distribution List

m ISO27035:2016 and NIST

Change Description
Final Version
 RACI matrix for Incident Management

A Responsible, Accountable, Consulted, and Informed (RACI) matrix is used to describe the roles and responsibilities of various
roles in operating the incident management process (es).

It is especially useful in clarifying roles and responsibilities in cross-functional/departmental projects and processes.

The following table provides <organisation name> an incident management RACI matrix, which is to be made available to its IRT
and IRM teams.

>

>

>

>

>

>
LE

LE

LE

LE

LE

LE
RO

RO

RO

RO

RO

RO
LE

LE

LE

LE

LE

LE
MP

MP

MP

MP

MP

MP
XA

XA

XA

XA

XA

XA
<E

<E

<E

<E

<E

<E
Stage Activity
Identification Incident Logging and Categorisation A I R
Identification Incident Assignment A R
Identification Identification - assess the loss A C/I R C/I
Containment Containment - stop the loss A C/I R C/I
Eradication Eradication and remediation A C/I R C/I
Recovery Recovery - Corrective action A C/I R I I
Recovery Incident Review and Closure A C/I R I I
Lessons learned Lessons learned – corrective planning A C/I R I I
Containment Incident Escalation R/A R I
Recovery SLA Monitoring A/I I I R
Recover OLA and UC   Monitoring A/I R I
Recovery Complaint Handling A/I R C/I

R – Responsible, A – Accountable, C – Communicated, I – Informed

Operational Level agreements (OLA) and underpinning contracts (UC) would need to be taken in to
consideration as currently <CLIENT> doesn’t have SLAs enforced. Also OLA and UC will assist with the
creation of SLAs.
 RACI matrix for Incident Management

ties of various

s.

ilable to its IRT

 ISO27035:2016 - Part 1 Compliance Assessment Result
Implementation
Clause Clause Title Fully Partial Not
4.2 Objectives of Incident Management 2 4 0
4.3 Benefits of a structure approach N/A N/A N/A
4.4 Adaptability 3 1 0
5.2 Plan & Prepare 5 3 0
5.3 Detect & Report 5 3 0
5.4 Assessment & Decision 5 2 0
5.5 Responses 8 8 0
5.6 Lessons Learnt 3 1 3
31 22 3

ISO27035:2016 - Part 2 Compliance Assessment Result

Implementation
Clause Clause Title Full Partial Not
4.1 Information security incident management policy 4 0 0
4.2 Involved Parties 3 2 0
4.3 Information Security Management Content 19 3 5
5.1 Updating Information Security Polices 3 1 0
5.2 Linking of Policy Documents 1 0 1
6.1 Creating Incident Management Plan 9 0 0
6.2 Plan is built on consensus 1 2 0
6.3 Involved Parties 2 2 1
6.4 Incident Response Plan Content 38 13 2
6.5 Incident Classification Scale 2 0 0
6.6 Incident Forms 5 1 1
6.7 Process & Procedures 10 1 1
6.8 Trust & Confidence 5 1 0
6.9 Handling Confidential or Sensitive Information 0 1 0
102 27 11
 Total Controls
Assessed
N/A
0 6 FULL 31
5%
N/A N/A PARTIAL 22
0 4 NOT 3
0 8 N/A 0
0 8
0 7
0 16 39%
0 7
55%
0 56

FULL PARTIAL NOT N/A

Total Controls
Assessed
N/A 8%
0 5 FULL 102
0 5 PARTIAL 27
0 27 NOT 11
19%
0 4 N/A 0
0 2
0 9
0 3
0 5
0 53
0 2
0 7 73%
0 12
0 6
0 1
0 141

FULL PARTIAL NOT N/A

 ISO27035:2016 Part 1 - Clause Assessment Result
9 Fully;
Partial;
8 8
8
7
6 Fully; 5 Fully; 5 Fully; 5
5 Partial; 4
4 Fully; 3 Partial; 3 Partial; 3 Fully; 3
3 Fully; 2 Partial; 2
2 Partial; 1 Parti
1 0N/A; 0 0N/A; 0 0N/A; 0 0N/A; 0 0N/A; 0 0N/A; 0
0
t ty e rt on s
en ili ar po i se
e m ab rep R e cis on Le
a
ag ap
t P & De s p s
an Ad
& ct Re so
n
a n te t& s
tM Pl De en Le
en sm
ic d es
In s
f As
so
ti ve
c
je
Ob

Fully Partial Not N/A

ISO27035:2016 Part 2 - Clause Assessment Result

40 38

35

30

25

20 19

15 13

10 9

4 5
5 32 3 3
00 0 10 101 00 120 221 2 2
00
0
y s t s ts n s s t e
ol
ic
rti
e en ice en la su tie en al
p Pa ont Pol m n tP s en Par o nt Sc
t cu C on
en d tC rit
y e
co
n d n
m lve en Do em l ve la ati
e vo m cu ic y a g on
v o P ifi
c c
ag In ge Se ol an ilt In se ss In
an a n P u
po
n l a
m an ati
o of tM is
b
es
C
nt M m ng en n R e nt
e y r i ci d a
cid rit fo k Pl en
t cid
in e cu In Lin g
In id In
y S g n c
rit n tin ati In
e cu a tio pda C re
s U
on rm
ati nfo
I
rm
fo
In

Full Partial Not N/A

Result
Fully;
Partial;
8 8

Fully; 3 3
2
Partial; 1
0N/A; 0 0N/A; 0 N/A; 0
s t
se a rn
pon Le
s s
Re so
n
s
Le

Assessment Result
38

13
10

5 5
221 2 2 11 11 10
0 00 010
s t e s s ce on
rti
e en al m re en
nt Sc or du ati
Pa Co
on t F e nfi
d
rm
d n en oc fo
ve a ca
ti Pr Co In
ol Pl is fi cid &
nv se s In s& st ve
on la ces Tru n siti
e s p
ntC Pr
o Se
tR cid
e
l or
en In tia
ic d
In den
nfi
Co
g
in
ndl
Ha

N/A
 Clause Title : ISO27035 Part 1 Sub Control Reference
4.2 4.3 4.4 5.2 5.3 5.4
Benefits of a
Objectives of Incident Plan & Assessment &
structure Adaptability Detect & Report
Management Prepare Decision
approach
4.2.a N/A 4.4a 5.2.a 5.3.a 5.4.a
4.2.b 4.4b 5.2.b 5.3.b 5.4.b
4.2.c 4.4c 5.2.c 5.3.c 5.4.c
4.2.d 4.4d 5.2.d 5.3.d 5.4.c 1
4.2.e 5.2.e 5.3.e 5.4.c.2
4.2.f 5.2.f 5.3.f 5.4.c.3
5.2.g 5.3.g 5.4.c.4
5.2.h 5.3.h

Cl
4.1 4.2 4.3 5.1 5.2

Information security Updating

Involved Information Security Linking of Policy
incident management Information Security
Parties Management Content Documents
policy Polices
4.1.a 4.2.a 4.3.a.2 4.3.o 5.1.a 5.2.a
4.1.b 4.2.b 4.3.b.1 4.3.p 5.1.b 5.2.b
4.1.c 4.2.c 4.3.b.2 4.3.q 5.1.c
4.1.d 4.2.d 4.3.c 4.3.q.1 5.1.d
4.1.e 4.2.e 4.3.d 4.3.q.2
4.3.e 4.3.q.3
4.3.f 4.3.q.4.a
4.3.g 4.3.q.4.b
4.3.h 4.3.q.5
4.3.i 4.3.q.6
4.3.j.1 4.3.q.7
4.3.j.2
4.3.k
4.3.l
4.3.m
4.3.n
rence
5.5 5.6 Compliance Le
The compliance map provides a high level view of the assessment status of the
Responses Lessons Learnt understanding of the assessment, the following compliance ratings have been d

5.5.a 5.6.a Fully implemented, documented and considered appropriate t

5.5.b 5.6.b Partially implemented and documented. Stakeholders to revie
5.5.c 5.6.c Not implemented. Stakeholders to review and consider action
5.5.c 1 5.6.d Deemed no applicable in the context of the scope of requirem
5.5.c.2 5.6.e
5.5.c.3 5.6.f
5.5.c.4 5.6.g
5.5.c.5
5.5.c.6
5.5.c.7
5.5.c.8
5.5.c.9
5.5.c.9.a
5.5.c.9.b
5.5.c.9.c
5.5.c.10

Clause Title : ISO27035 Part 1 Sub Control Reference

6.1 6.2 6.3 6.4
Creating
Incident Plan is built on Involved
Incident Response Plan Content
Management consensus Parties
Plan
6.1.a 6.2.1 6.3 6.4.a.1 6.4.b 6.4.d.1 6.4.f
6.1.b 6.2.2 6.3.a 6.4.a.2 6.4.b.1 6.4.d.2 6.4.f.1
6.1.c 6.2.3 6.3.b 6.4.a.3 6.4.b.2 6.4.d.3 6.4.f.2
6.1.d 6.3.c 6.4.a.4 6.4.b.3 6.4.d.4 6.4.f.3
6.1.e 6.3.d 6.4.a.5 6.4.b.4 6.4.d.5 6.4.f.4
6.1.f 6.4.a.6 6.4.b.5 6.4.d.6 6.4.f.5
6.1.g 6.4.a.7 6.4.b.6 6.4.d.7 6.4.f.6
6.1.h 6.4.a.8 6.4.b.7 6.4.d.8
6.1.i 6.4.a.9 6.4.b.8 6.4.d.9
6.4.a.10 6.4.c 6.4.d.10
6.4.a.11 6.4.c.1 6.4.d.11
6.4.a.12 6.4.c.2 6.4.d.12
6.4.a.13 6.4.c.3 6.4.d.13
6.4.a.14 6.4.c.4 6.4.d.14
6.4.c.5 6.4.e
6.4.c.6
6.4.c.78
 Compliance Legend
of the assessment status of the control status for part 1 and 2 of the Standard. To provide an
compliance ratings have been defined:

ed and considered appropriate to meeting the standard.

umented. Stakeholders to review recommendations and manage accordingly.
s to review and consider actions as requirement to meet the standard.
ontext of the scope of requirements.

6.5 6.6 6.7 6.8 6.9

Incident
Incident Process & Trust & Handling Confidential of
Classification
Forms Procedures Confidence Sensitive Information
Scale
6.5.1 6.6.1 6.7.1 6.8.1 6.9.1
6.5.2 6.6.2 6.7.2 6.8.2
6.6.3 6.7.3 6.8.3
6.6.4 6.7.3.a 6.8.4
6.6.5 6.7.3.b 6.8.5
6.6.6 6.7.3.c 6.8.6
6.6.7 6.7.3.d
6.7.3.e
6.7.3.f
6.7.3.g
6.7.3.h
6.7.3.i
 ISO/IEC 27035-1, Principles of Incident Management.

Presents basic concepts and phases of information security incident management, and how to improve
-- detecting,
-- reporting,
-- assessing,
-- responding to incidents, and
-- applying lessons learnt.
Clause
4.2
As a key part of an organisation’s overall information security strategy, the organisation should put con
information security incidents in order to minimize the direct and indirect damage to its operations caus
security management.

Compliancy
4.2
Status

Partial 4.2.a

Partial 4.2.b

Full 4.2.c

Full 4.2.d

Partial 4.2.e

Partial 4.2.f

4.3
The clauses are not included in the assessment as there are no applicable controls
4.4
The guidance provided by ISO/IEC 27035 (all parts) is extensive and, if adopted in full, could require s
management and the complexity of the mechanisms implemented are proportional to the following Cla

Full 4.4a
Partial 4.4b
Full 4.4c
Full 4.4d

5.2
Effective information security incident management requires appropriate planning and preparation. For
Full 5.2.a

Full 5.2.b

Full 5.2.c

Full 5.2.d

Full 5.2.e
Partial 5.2.f

Partial 5.2.g

Partial 5.2.h

5.3
The second phase of information security incident management involves the detection of, collection of
yet be classified as information security incidents. The reporting of security events in line with the organ
For the Detection and Reporting phase, an organisation should undertake the following key activities:

Partial 5.3.a
Full 5.3.b

Full 5.3.c

Full 5.3.d

Full 5.3.e

Partial 5.3.f

Partial 5.3.g
Full 5.3.h

5.4
The third phase of information security incident management involves the assessment of information a
activities should be performed:

Full 5.4.a

Partial 5.4.b
Partial 5.4.c

Full 5.4.c 1

Full 5.4.c.2

Full 5.4.c.3

Full 5.4.c.4

5.5
The fourth phase of information security incident management involves responding to information secu
could involve information security investigation Once an information security incident has been confirm

Full 5.5.a

Partial 5.5.b

Partial 5.5.c

Full 5.5.c 1

Full 5.5.c.2

Full 5.5.c.3

Partial 5.5.c.4
Full 5.5.c.5

Partial 5.5.c.6

Partial 5.5.c.7
Partial 5.5.c.8

Partial 5.5.c.9
Full 5.5.c.9.a
Partial 5.5.c.9.b
Full 5.5.c.9.c
Full 5.5.c.10

5.6
The fifth phase of information security incident management occurs when information security incidents

Full 5.6.a

Full 5.6.b

Full 5.6.c
 Partial 5.6.d

Incomplete 5.6.e

Incomplete 5.6.f

Incomplete 5.6.g
ISO/IEC 27035-1, Principles of Incident Management.

Presents basic concepts and phases of information security incident management, and how to improve incident management. This pa
-- detecting,
-- reporting,
-- assessing,
-- responding to incidents, and
-- applying lessons learnt.
ISO 27035:1 Clause Statements
Objectives of Incident Management
As a key part of an organisation’s overall information security strategy, the organisation should put controls and procedures in place to
information security incidents in order to minimize the direct and indirect damage to its operations caused by the incidents. Since dam
security management.

More specific objectives of a structured well-planned approach to incident management should

include
the following:
Information security events are detected and dealt with efficiently, in particular deciding when they
should be classified as information security incidents;
Identified information security incidents are assessed and responded to in the most appropriate and
efficient manner;
The adverse effects of information security incidents on the organisation and its operations are
minimized by appropriate controls as part of incident response;
A link with relevant elements from crisis management and business continuity management through
an escalation process is established;
Information security vulnerabilities are assessed and dealt with appropriately to prevent or reduce
incidents. This assessment can be done either by the IRT or other teams within the organisation,
depending on duty distribution;
Lessons are learnt quickly from information security incidents, vulnerabilities and their management.
This feedback mechanism is intended to increase the chances of preventing future information
security incidents from occurring, improve the implementation and use of information security
controls, and improve the overall information security ident management plan.

Benefits of a structure approach

The clauses are not included in the assessment as there are no applicable controls
Adaptability
The guidance provided by ISO/IEC 27035 (all parts) is extensive and, if adopted in full, could require significant resources to operate a
management and the complexity of the mechanisms implemented are proportional to the following Clauses.

Size, structure and business nature of an organisation including key critical assets, processes, and
data that should be protected;
Scope of any information security management system for incident handling;
Potential risk due to incidents;
The goals of the business.

Plan and Prepare

Effective information security incident management requires appropriate planning and preparation. For an efficient and effective inform
Formulate and produce an information security incident management policy and gain top
management commitment to that policy;

Update information security policies, including those related to risk management, at a corporate level
and specific system, service and network levels;

Define and document a detailed information security incident management plan, including topics
covering communications and information disclosure;

Establish the IRT, with an appropriate training program designed, developed, and provided to its
personnel;

Establish and preserve appropriate relationships and connections with internal and external
organisations that are directly involved in information security event, incident and vulnerability
management;
 Establish, implement and operate technical, organisational and operational mechanisms to support
the information security incident management plan and the work of the IRT. Develop and deploy
necessary information systems to support the IRT, including an information security database. These
mechanisms and systems are intended to prevent information security incident occurrences or reduce
the likelihood of occurrences of information security incidents;

Design and develop an awareness and training program for information security event, incident and
vulnerability management;

Test the use of the information security incident management plan, its processes and procedures.

Detect & Report

The second phase of information security incident management involves the detection of, collection of information associated with, an
yet be classified as information security incidents. The reporting of security events in line with the organisation’s reporting policies ena
For the Detection and Reporting phase, an organisation should undertake the following key activities:

Monitor and log system and network activity of constituency or parent organisations as appropriate;
Detect and report the occurrence of an information security event or the existence of an information
security vulnerability, whether manually by personnel or automatically;
Collect information on an information security event or vulnerability;

Collect situational awareness information from internal and external data sources including local
system and network traffic and activity logs, news feeds concerning ongoing political, social, or
economic activities that might impact incident activity, external feeds in incident trends, new attack
vectors, current attack indicators and new mitigation strategies and technologies;

Ensure that all activities, results and related decisions are properly logged for later analysis;
Ensure that digital evidence is gathered and stored securely, and that its secure preservation is
continually monitored, in case the evidence is required for legal prosecution or internal disciplinary
action. For more detailed information on the identification, collection, acquisition and preservation of
digital evidence, see the investigative standards in Annex A;
Ensure that a change control regime is followed to enable information security event and vulnerability
tracking and report updates, and to keep the information security database up-to-date;
Escalate, on an as-needed basis throughout the phase, for further review or decisions.

Assessment and Decision

The third phase of information security incident management involves the assessment of information associated with occurrences of in
activities should be performed:

Distribute the responsibility for information security incident management activities through an
appropriate hierarchy of personnel with assessment, decision making and actions involving both
security and non-security personnel;
Provide formal procedures for each notified person to follow, including reviewing and amending
reports, assessing damage, and notifying relevant personnel. Individual actions will depend on the
type and severity of the incident;
 Use guidelines for thorough documentation of an information security event and the subsequent
actions for an information security incident if the information security event becomes classified as an
information security incident.
Collect information that can include testing, measuring, and other data gathering about the detection
of an information security event. The type and amount of information collected will depend on the
information security event that has occurred;
Conduct an assessment by the incident handler to determine whether the event is a possible or
confirmed information security incident or a false alarm. A false alarm (i.e. a false positive) is an
indication of a reported event that is found not to be real or of any consequence. If desired, the IRT
can conduct a quality review to ensure that the incident handler correctly declared an incident;

Ensure that all parties involved, particularly the IRT, properly log all activities, results and related
decisions for later analysis;
Ensure that the change control regime is maintained to cover information security incident tracking
and incident report updates, and to keep the information security database up-to-date.

Responses
The fourth phase of information security incident management involves responding to information security incidents in accordance with
could involve information security investigation Once an information security incident has been confirmed and the responses determin

Distribute the responsibility for information security incident management activities through an
appropriate hierarchy of personnel with decision making and actions, involving both security and non-
security personnel as necessary;
Provide formal procedures for each involved person to follow, including reviewing and amending the
reports, re-assessing damage, and notifying the relevant personnel. Individual actions will depend on
the type and severity of the incident;
Use guidelines for thorough documentation of an information security incident and subsequent
actions.
Investigate incidents as required and relative to the information security incident classification scale
rating. The scale should be changed as necessary. Investigation can include different kinds of
analyses to provide a more in-depth understanding of incidents.
Review by the IRT to determine whether the information security incident is under control, and if so,
perform the required response. If the incident is not under control or it is going to have a severe
impact on the organisation’s operations, perform crisis response activities through escalation to the
crisis handling function.
Assign internal resources and identify external resources in order to respond to an incident.

Escalate as needed throughout the phase for further assessments or decisions.

Ensure that all parties involved, particularly the IRT, properly log all activities for later analysis.

Ensure that digital evidence is gathered and stored provably securely, and that its secure
preservation is continually monitored, in case the evidence is required for legal prosecution or internal
disciplinary action. For more detailed information on the identification, collection, acquisition and
preservation of digital evidence, see the investigative standards in Annex A.
Ensure that the change control regime is maintained to cover information security incident tracking
and incident report updates, and to keep the information security database up-to-date.
 Communicate the existence of the information security incident and share any relevant details (e.g.
threat, attack, and vulnerability information) with other internal and external individuals or
organisations, in accordance with organisational and IRT communication plans and information
disclosure policies.

It can be particularly important to notify asset owners (determined during the impact analysis) and
internal and external organisations (e.g. other incident response teams, law enforcement agencies,
Internet service providers, and information sharing organisations) that could assist with the
management and resolution of the incident.

Sharing information could also benefit other organisations since the same threats and attacks often
affect multiple organisations. For further detail about information sharing, see ISO/IEC 27010.

After recovery from an incident, a Post Incident Activity should be initiated depending on the nature
and severity of the incident. This activity includes
Investigation of the information pertaining to the incident,
Investigation of other relevant sources such as involved personnel, and
Summarized report of the investigation findings.
Once the incident has been resolved, it should be closed according to the requirements of the IRT or
parent organisation and all stakeholders should be notified.

Lessons Learnt
The fifth phase of information security incident management occurs when information security incidents have been resolved. This pha

Identify the lessons learnt from information security incidents and vulnerabilities;

Review, identify and make improvements to information security control implementation (new or
updated controls), as well as information security incident management policy. Lessons can come
from one or many information security incidents or reported security vulnerabilities. Improvements
are aided by metrics fed into the organisation’s strategy on where to invest in information security
controls;

Review, identify and make improvements to the organisation’s existing information security risk
assessment and management reviews;
Review how effective the processes, procedures, reporting formats and organisational structure were
in responding to, assessing and recovering from information security incidents and dealing with
information security vulnerabilities. On the basis of the lessons learnt, identify and make
improvements to the information security incident management plan and its documentation;

Communicate and share the results of review within a trusted community (if the organisation so
wishes);

Determine if the incident information, associated attack vectors and vulnerabilities may be shared with
partner organisations to assist in preventing the same incidents from occurring in their environments.
For more details, see ISO/IEC 27010 on information sharing;

Perform a comprehensive evaluation of IRT performance and effectiveness on a periodic basis.

ve incident management. This part combines these concepts with principles in a structured approach to:

ntrols and procedures in place to enable a structured well-planned approach to the management of information security incidents. From
sed by the incidents. Since damage to information assets can have a negative impact on operations, business and operational perspec

Observation

significant resources to operate and manage. It is therefore important that an organisation applying this guidance should retain a sense
auses.

Observation

or an efficient and effective information security incident management plan to be put into operation, an organisation should complete a n
Observation
f information associated with, and reporting on occurrences of information security events and the existence of information security vuln
anisation’s reporting policies enables later analysis if required.

Observation

associated with occurrences of information security events and the decision on whether to classify events as information security incide

Observation
urity incidents in accordance with the actions determined in the Assessment and Decision phase. Depending on the decisions, the resp
med and the responses determined, the subsequent activities should be undertaken:

Observation
ts have been resolved. This phase involves learning lessons from how incidents (and vulnerabilities) have been handled. For the Lesso

Observation
Cyber Incident Response Plan - Lessons Learned & Case Management Phase - refers to: " this is the point where normal
operations are restored. Eradication and recovery have been tested and approved and required software patches have bee
installed, operational changes have been made through Change Control practices and documented.

It is the responsibility of the IRM's to pull together all the documentation and evidence about the incident and create and Inc
Response Report. The draft should contain information of what occurred during the incident and the remediation processes
this report has been created, the IRM's will formally review the information with those that were impacted and those who
participated in handling the incident.

Gather all information regarding the incident and analytical documentation combined with any associated legal case informa
Incident reports must define the incident in detailed terms. If the case is to be prosecuted, a legal chain of evidence may be
required.

Cyber incidents are captured, tracked and remediated in the Operational Risk Register and aligns to the Enterprise Risk Re
ensure that cyber incidents are known, managed and do not adversely affect the <CLIENT> operations.

The CTO is accountable for ensuring that IT risk is reduced. The CTO reviews the risk register on a monthly basis, where c
the business risk team has completed updating the register.

Cyber incidents are captured, tracked and remediated in the Operational Risk Register and aligns to the Enterprise Risk Re
ensure that cyber incidents are known, managed and do not adversely affect the <CLIENT> operations.

The CTO is accountable for ensuring that IT risk is reduced. The CTO reviews the risk register on a monthly basis, where c
the business risk team has completed updating the register.
No effective testing has taken place (only 1 test has taken place) to validate cyber incident response

The Cyber Incident Response Plan - Lessons Learned & Case Management Phase - states that "The Incident Response T
then compile and submit the final report to Management and the Case Management team. Ideally, this is to occur as soon
possible after the incident.

However, as there has not been a complete test of the incident response phases (or an incident has occurred to invoke a
requirement for this control) it is not known if this has taken place.

The Cyber Incident Response Plan - Lessons Learned & Case Management Phase - states that "The Incident Response T
then compile and submit the final report to Management and the Case Management team. Ideally, this is to occur as soon
possible after the incident.

However, as there has not been a complete test of the incident response phases (or an incident has occurred to invoke a
requirement for this control) it is not known if this has taken place.

This has not taken place.

 Recommendation

om an organisation’s perspective, the prime objective is to avoid or contain the impact of

ectives should have a major influence in determining more specific objectives for information

Recommendation

se of perspective and ensure that the resources applied to information security incident

Recommendation

a number of preparatory activities, namely:

Recommendation
ulnerabilities by manual or automatic means. In this phase, events and vulnerabilities might not

Recommendation

dents. Once an information security event has been detected and reported, the subsequent

Recommendation
sponses could be made immediately, in real-time, or in near real-time, and some responses

Recommendation
sons Learnt phase, an organization should perform the following key activities:

Recommendation
No further requirement.

No further requirement.

No further requirement.
Conduct a cyber based incident response test on an annual basis, based on the
latest threat scenario, or the following:
- Unauthorised access
- Denial of Service
- Scans/Probes/Attempted access
- Malware Infection
- Data Breach

- NCC Group has been engaged to conduct a cyber incident response test, to
understand and assist improvement of <CLIENT>'s incident response plan.

- NCC Group has been engaged to conduct a cyber incident response test, to
understand and assist improvement of <CLIENT>'s incident response plan.

- NCC Group has been engaged to conduct a cyber incident response test, to
understand and assist improvement of <CLIENT>'s incident response plan.
NIST SP800-61

3.2 - Detection and Analysis

3.2.4 - Incident Analysis

3.1.2 - Preventing Incidents

3.2.7 - Incident Notification

3.2.4 - Incident Analysis

3.4.1 - Lessons Learned

Not Applicable
Not Applicable
Not Applicable
Not Applicable
2.3.1 - Policy Elements

2.3.1 - Policy Elements

2.3.2 - Plan Elements

2.4 - Incident Response Team Structure

2.3.4 - Sharing Information with Outside Parties

2.4.4 - Dependencies within Organisations

3.1.1 - Preparing to Handle Incidents

3.1.1 - Preparing to Handle Incidents

3.2.3 - Source of Precursors & Indicators

3.2.3 - Source of Precursors & Indicators
3.2.4 - Incident Analysis, 3.2.5 - Incident
Documentation

2.3.4 - Sharing Information with Outside Parties

3.2.1 - Attack Vectors

3.4.3 - Evidence Retention

3.2.5 - Incident Documentation

3.1.1 - Preparing to Handle Incidents

3.2.6 - Incident Prioritisation

2.4.1 - Team Models

2.3.3 - Procedure Elements

2.3.3 - Procedure Elements

3.4.2 - Using Collected Incident Data

3.2.4 - Incident Analysis

3.4.3 - Evidence Retention

4.1.2 - Sharing Agreements and Reporting

Requirements

2.4.1 - Team Models

2.3.3 - Procedure Elements

2.3.2 - Plan Elements

3.2.6 - Incident Prioritisation

3.3.1 - Containment Strategy

2.4.1 - Team Models

2.4.2 - Team Selection
2.4.3 - Incident Response Personnel
2.4.4 - Dependencies within Organisations
3.2.7 - Incident Notification
3.2.4 - Incident Analysis
3.2.5 - Incident Documentation

3.4.3 - Evidence Retention

4.1.2 - Sharing Agreements and Reporting

Requirements
4.1.2 - Sharing Agreements and Reporting
Requirements

3.2.4 - Incident Analysis

3.2.4 - Incident Analysis
3.2.5 - Incident Documentation
4.1.2 - Sharing Agreements and Reporting
Requirements

3.4.1 - Lessons Learned

3.4.1 - Lessons Learned

3.4.1 - Lessons Learned

3.4.1 - Lessons Learned

3.4.1 - Lessons Learned

4.1.2 - Sharing Agreements and Reporting

Requirements

3.4.1 - Lessons Learned

 ISO/IEC 27035-2, Guidelines to plan and prepare for incident response.
Clause
4.1
An organisation information security incident management policy should provide the formally documen
should be part of the information security strategy for an organisation. It should also support the existin
persons, authority and reporting lines (specifically the primary point of contact for reporting suspected i
Compliancy should also outline any awareness and training initiatives within the organisation. that is related to incid
Status

Full 4.1a
Full 4.1b
Full 4.1c
Full 4.1d
Full 4.1e

4.2
A successful information security incident management policy should be created and implemented as a

Full 4.2.a

Full 4.2.b

Full 4.2.c
Partial 4.2.d
Partial 4.2.e

4.3
The information security incident management policy should be high-level. Detailed information and ste
incident management policy content addresses, but is not limited to, the following topics:

Full 4.3.a.2
Full 4.3.b.1
Full 4.3.b.2
Incomplete 4.3.c
Full 4.3.d
Full 4.3.e
Full 4.3.f
Full 4.3.g
Full 4.3.h
Full 4.3.i

Full 4.3.j.1
 Full 4.3.j.1

Full 4.3.j.2

Full 4.3.k

Partial 4.3.l

Full 4.3.m

Full 4.3.n

Partial 4.3.o

Full 4.3.p

Partial 4.3.q

Full 4.3.q.1

Incomplete 4.3.q.2

Incomplete 4.3.q.3
Full 4.3.q.4.a

Full 4.3.q.4.b

Incomplete 4.3.q.5

Full 4.3.q.6

Incomplete 4.3.q.7

5
An organisation. should include information security incident management content in its information se

5.1
 Full 5.1.a

Full 5.1.b

Partial 5.1.c

Full 5.1.d

5.2
An organisation. should update and maintain its corporate information security and risk management p
management policy and associated The corporate-level policies should include the requirement that a
information security vulnerabilities is used as input to the process designed to maintain continuing effec

Incomplete 5.2.a

Full 5.2.b

6
The aim of an information security incident management plan is to document the activities and procedu
documentation should encompass multiple documents including the forms, procedures, organisation.a
basic flow of incident management activities to provide structure and pointers to the various detailed co
information security incident management plan comes into effect whenever an information security eve

6.1
Full 6.1.a

Full 6.1.b

Full 6.1.c

Full 6.1.d

Full 6.1.e

Full 6.1.f

Full 6.1.g

Full 6.1.h

Full 6.1.i

6.2
This part of ISO/IEC 27035 recommends the development of an information security incident managem
communication, and relationships with external organisation's. Terms and definitions should be norma
 communication, and relationships with external organisation's. Terms and definitions should be norma
incident management plan should include standard terms and definitions in a glossary.

Full 6.2.1

Partial 6.2.2

Partial 6.2.3

6.3
An organisation should ensure that the information security incident management plan is acknowledge

Incomplete 6.3

Full 6.3.a

Partial 6.3.b

Full 6.3.c

Partial 6.3.d

6.4
6.4.a
Key decision-making criteria and processes to support expected management phases should be define
and contribution from participants and management support.
The content of the information security incident management plan should give an overview, as well as

Full 6.4.a.1
Full 6.4.a.2
Full 6.4.a.3
Partial 6.4.a.4
Full 6.4.a.5
Partial 6.4.a.6

Full 6.4.a.7
 Full 6.4.a.7

Partial 6.4.a.8
Partial 6.4.a.9
Partial 6.4.a.10
Full 6.4.a.11
Full 6.4.a.12
Full 6.4.a.13
Partial 6.4.a.14
Full 6.4.b

Full 6.4.b.1

Full 6.4.b.2

Full 6.4.b.3

Full 6.4.b.4

Full 6.4.b.5

Full 6.4.b.6
Partial 6.4.b.7
Full 6.4.b.8
Full 6.4.c

Full 6.4.c.1

Full 6.4.c.2

Full 6.4.c.3
Full 6.4.c.4
Full 6.4.c.5

Full 6.4.c.6
Full 6.4.c.78
6.4.d

Full 6.4.d.1

Full 6.4.d.2

Full 6.4.d.3
 Full 6.4.d.3

Partial 6.4.d.4

Partial 6.4.d.5
Incomplete 6.4.d.6
Full 6.4.d.7
Full 6.4.d.8
Incomplete 6.4.d.9
Full 6.4.d.10

Full 6.4.d.11
Full 6.4.d.12
Full 6.4.d.13
Full 6.4.d.14

Full 6.4.e

Partial 6.4.f
Full 6.4.f.1

Partial 6.4.f.2

Full 6.4.f.3

Partial 6.4.f.4

Full 6.4.f.5
Partial 6.4.f.6

6.5
An information security event/incident classification scale should be used to grade events/incidents. In

Full 6.5.1

Full 6.5.2

6.6
Incident forms, if used, should be created before they are needed. The number, type and format of the
where existing forms are not sufficient or an appropriate form has not yet been created.
Full 6.6.1
 Full 6.6.2
Incomplete 6.6.3

Full 6.6.4

Full 6.6.5

Partial 6.6.6

Full 6.6.7

6.7
Before being able to commence operation of the information security incident management plan, it is im

Full 6.7.1

Full 6.7.2

Full 6.7.3
Full 6.7.3.a

Full 6.7.3.b

Full 6.7.3.c

Full 6.7.3.d

Full 6.7.3.e

Full 6.7.3.f

Full 6.7.3.g

Incomplete 6.7.3.h

Partial 6.7.3.i

6.8
The IRT plays a crucial role for the overall information security of an organisation. The IRT requires the
trust within the organisation. is created by fiat and stems from the support given by the top managemen

Full 6.8.1
 Partial 6.8.2

Full 6.8.3

Full 6.8.4

Full 6.8.5

Full 6.8.6

6.9
An information security incident management plan may contain sensitive information and people involv
required (e.g. when leaving the protective domain of the IRT). If information security events/incidents/v
omitted information, this can lead to a situation where the IRT will maintain its own information security

Partial 6.9.1

7
NOTE Clause 7, in its entirety, links to ISO/IEC 27035-1:2016, 5.2 d).
8
NOTE Clause 8, in its entirety, links to ISO/IEC 27035-1:2016, 5.2 e).
9
NOTE Clause 9, in its entirety, links to ISO/IEC 27035-1:2016, 5.2 f).
10
NOTE Clause 10, in its entirety, links to ISO/IEC 27035-1:2016, 5.2 g).
11
NOTE Clause 11, in its entirety, links to ISO/IEC 27035-1:2016, 5.2 h.
12
NOTE Clause 12, in its entirety, links to ISO/IEC 27035-1:2016, 5.6.
SO/IEC 27035-2, Guidelines to plan and prepare for incident response.
ISO27035:2 Clause Statements
Information security incident management policy
n organisation information security incident management policy should provide the formally documented principles and intentions used
hould be part of the information security strategy for an organisation. It should also support the existing mission of its parent organisatio
ersons, authority and reporting lines (specifically the primary point of contact for reporting suspected incidents) when an information sec
hould also outline any awareness and training initiatives within the organisation. that is related to incident response (see Clause 10). Th

a)    Objectives
b)    Interested Parties internally & externally
c)    Specific incident types and vulnerabilities are highlighted
d)    Specific roles are highlighted
e)    Benefits are understood

Involved Parties
successful information security incident management policy should be created and implemented as an enterprise-wide process. To tha

The incident management policy has been created and implemented as an enterprise wide process.
The incident management policy has had involvement from:
Legal advisors
public relations
marketing
departmental managers
security staff
risk managers
system and network administrators
ICT staff,
Helpdesk staff
Upper-level management
Facilities managers
The incident management policy is approved by top management
The incident management policy is adequately resourced to maintain an incident response capability
The incident management policy is made available to all staff

Information Security Management Content

he information security incident management policy should be high-level. Detailed information and step-by-step instructions should be i
ncident management policy content addresses, but is not limited to, the following topics:

The incident management policy includes, purpose objectives and scope

Ownership
Review cycle
A statement relating to top management commitment
A definition of a security incident
Description of the types or categories of security incident
A description of how incidents should be reported
Process flow map of the incident process from detection to resolution
A requirement for post incident review
(if appropriate) summary of vulnerability reporting and handling
Defined roles and responsibilities
Overview of the IRT
Organisation
Key roles
 Responsibilities
Authority
Defined decision making authority for each phase and priority
Definitions of:
·         Incident classification
·         Severity rating
·         Related terms
Overview of:
Reporting and notification requirements
Briefing top management
Dealing with enquiries, instigating follow up and resolving incidents
Liaising with external organisations
Requirements for logging
Requirements for log analysis
The requirement that all parts of the organisation work together to identify and resolve incidents.

A description of the oversight structure and its duties and authority.

Links to external organisations for specific support purposes such as forensics teams legal counsel, IT
operations and media support.

Summary of legal and regulatory compliance requirements and relevant contacts.

List and references to associated policies procedures and documents that support the incident
management process .

Incident Management Plan

Continuous monitoring policy which is shared across the whole business stating that this activity is
undertaken

Authority granting the IRT access to the outputs of the monitoring or the ability to access logs from 3 rd
parties
Information sharing and disclosure policy
Communications policy setting how and when information can be shared and with whom and any
associated authority and sign-off.

Does this follow the organisational requirements for disclosure?

Information storage and handling policy

Secure storage and handling
This should be compatible with the document classification, labelling and handling policy
IRT
·         Mission statement
·         Goals and purpose
·         Definition of the IRT scope
·         Details of top management sponsor / executive officer, board member
·         IRT authority
·         Contact information
·         List of services and core activities
·         Scope of authority
·         Governance structure
An overview of the awareness training process and use of incidents to feed into the process

Updating Information Security Policies

n organisation. should include information security incident management content in its information security policies at corporate level, a

General
 Describe why information security incident management is important

Indicate top management commitment

Ensure consistency across various policies

Ensure planned systematic and calm responses and minimise adverse effects.

Linking of Policy Documents

n organisation. should update and maintain its corporate information security and risk management policies, and specific system, servic
management policy and associated The corporate-level policies should include the requirement that appropriate review mechanisms ne
nformation security vulnerabilities is used as input to the process designed to maintain continuing effectiveness of the policies.

The Incident management policy should be linked to the:

Risk management policies

Information security policies

Review mechanisms should be implemented

Creating Incident Management plan

he aim of an information security incident management plan is to document the activities and procedures for dealing with information se
ocumentation should encompass multiple documents including the forms, procedures, organisation.al elements and support tools for th
asic flow of incident management activities to provide structure and pointers to the various detailed components of the plan. These com
nformation security incident management plan comes into effect whenever an information security event is detected or information secu

General: The plan should include a guide to:

Responding to an information security event

Determining type and priority

Managing to conclusion

Responding to vulnerabilities

Reporting requirements

Information storage requirements and format

Rules and circumstances in which information sharing with internal and external groups can take
place

Identification of lessons learned

Identification of improvement plan

Making the improvements happen

Plan is Built on consensus

his part of ISO/IEC 27035 recommends the development of an information security incident management policy. However, where there
ommunication, and relationships with external organisation's. Terms and definitions should be normalised between IRT members and p
ommunication, and relationships with external organisation's. Terms and definitions should be normalised between IRT members and p
ncident management plan should include standard terms and definitions in a glossary.

Ensure external and internal terminology is harmonised and understood by the IRT.

Ensure that roles and responsibilities with external support is harmonised and understood by the IRT.

Ensure external and internal metrics are harmonised and understood by the IRT.

Involved Parties
n organisation should ensure that the information security incident management plan is acknowledged by all personnel and associated

The Incident management plan should be acknowledged by all parties, staff, contractors and 3 rd
parties

The incident management plan should include the requirement for all parties to detect and report
information security events.

All parties shall assess and respond to events or incidents, be involved in post resolution activities
such as learning and improvement programmes.

Shall be willing participants of any IRT

Report vulnerabilities

Roles and responsibilities should be agreed between the organisation and the 3 rd parties.

Incident Response plan content

Plan and Prepare
ey decision-making criteria and processes to support expected management phases should be defined and reviewed before the planni
nd contribution from participants and management support.
he content of the information security incident management plan should give an overview, as well as specifying detailed activities. As n

Provides a standard approach for security event / incident classification and categorisation?
Provides a repository for managing and monitoring vulnerabilities
Provides a repository for managing and monitoring alerts
Provides guidance on escalation and to whom
Provides procedures for logging and log analysis can be conducted
Provides links to the change control processes
Procedures for evidence analysis
Provides guidance on using IDS / IPS devices (see also ISO 27039)
Ensures the correct legal and regulatory aspects have been addressed
Guidance on attacker surveillance
Procedures in operation to prevent an incident
Material for the training and awareness of later trainees
Procedures for the management of the testing plan
Organisational structure of the IRT
Terms of reference of the IRT
Important contact information
Procedures and guidance for information sharing
Detect and Report

Planning and preparation requirements for detection and reporting

Criteria for accepting an incident report

Reporting output notification – format of reports should be agreed.

Detecting and reporting the occurrence

Responding to incorrect use of the reporting process

Collecting information on incidents for further analysis

Detecting vulnerabilities
Recording information gathered in a central repository for future analysis
Assessment and decision
Plan and prepare the requirements for analysis and decision to enable and support the development
and operation of processes in response to an incident.

Minimum information needed for an incident to allow classification and prioritisation being able to
differentiate between false positives and true positives.

Operation functions and operation activities for automated tools is defined and managed.

The PoC should be able to establish whether the event should be classified as an incident
IRT assessment should confirm that it is an incident and should confirm the categorisation and
prioritisation
Assessment of vulnerabilities should be addressed. Who where and when the fix is going to be
applied should be identified
Record all assessment results
Responses

Planning and preparation requirements for response should enable and support the development and
operation of processes to respond to information security incidents. Prior to response planning, the
incident handling process owner should gather definitions or create working thresholds or categories
for priority of information and information system, impact of each intrusion types, damage scale,
intrusion alarm level, and severity. These can be qualitative or quantitative as long as they are
consistent with assessment and decision preparations, and enable the IRT manager to assign the
incident actions or tasks to responders.

Classes of response should also be defined prior to the planning process, organised by cost, time,
technical resource minimums, and other metrics to enable assignment of response class relative to
the known information about the reported and assessed incident. Immediate or deferred response
should be included, as well as a definition of how single or cyclic incident tasks will be managed in the
response process.

Review by the IRT to determine if the information security incident is under control;
 i)              if the incident is under control, instigate the required response, either immediately (in real-
time or in near real-time) or at a later time, and
ii)             if the incident is not under control or it is going to have a severe impact on the organisation’s
core services, instigate crisis activities through escalation to crisis handling function.
Defining a map of all internal and external functions and organisations that should be involved during
the management of an incident.
Containing and eradicating the information security incident as appropriate to mitigate or prevent the
scope and impact of the incident from increasing.
Conducting information security evidence analysis, as required.
Escalation, as required.
Ensuring that all involved activities are properly logged for later analysis.
Ensuring that electronic evidence is identified, collected/acquired and preserved.
Ensuring that the change control regime is maintained and thus that the information security database
is kept up-to-date.
Communicating the existence of the information security incident or any relevant details thereof to
other internal and external people or organisations.
Dealing with information security vulnerabilities.
Once the incident has been successfully dealt with, formally closing it and recording this in the
information security database.
Post-incident activity should include further analysis as required.
The organisation should ensure that the incident management plan allows for immediate and longer
term. Assessments should include short term and long term incident and should include unforeseen
and ad-hoc responses
Lessons Learned

Identifying the lessons learned from Information Security incidents and Vulnerabilities
Reviewing, identifying and making improvements to information security control implementation as
well as information security incident management policy and procedures as a result of lessons
learned.

Reviewing, identifying and if possible making improvements to the organisations existing information
security risk assessment and management review process as a result of the lessons learned process.

Reviewing how effective the processes, procedures reporting formats and / or the organisational
structure were in responding to assessing and recovering from each information security incident and
dealing with information security vulnerabilities, and on the basis of the lessons learned identifying and
making improvements to the information security incident management plan and it’s documentation.

Updating the information security database

Communicating and sharing the results of the review within a trusted community (as agreed within the
organisation).

Incident Classification Scale

n information security event/incident classification scale should be used to grade events/incidents. In any event, the decision should be

Is there a classification scale that is used to grade events/incidents available.

Is the scale used based on actual or projected adverse impacts on the organisations business
operations.

Incident Forms
ncident forms, if used, should be created before they are needed. The number, type and format of the forms should be determined by th
where existing forms are not sufficient or an appropriate form has not yet been created.
Does the organisation use defined incident response forms?
 Are the number, type and format of the form determined by the IRT?

Are they reviewed periodically for relevance and usability?

Is the form designed to capture descriptive text to provide a mechanism to capture information in
instances where existing norms are not sufficient or appropriate.

Are forms advertised and made available for users so that a person reporting an information security
event is familiar with them.

Are the forms standardised to enable a consistent and automated process?

Are the forms available in a paper based format in case the electronic scheme cannot be used?

Process and Procedures

efore being able to commence operation of the information security incident management plan, it is important that an organisation. has

Are there regular checks conducted to ensure that processes are readily available?
Does each document indicate those key stakeholder groups or individuals responsible for its use and
management?

Do the processes capture:

The reporting process for the handling of exceptions.
Guidance on the timing for getting approval from management in order to avoid any delay of
response;

Pre-authorised delegation of decision making without normal approval process.

Shutting down an affected system, service and/or network, in certain circumstances agreed by prior
arrangement with the relevant IT and/or business management;

Leaving an affected system, service and/or network, connected and running;

Monitoring data flowing from, to and within an affected system, service and/or network;

Activating normal back-up and crisis management procedures and actions in line with the system,

Monitoring and maintain the secure preservation of electronic evidence, in case it is required for legal
prosecution or internal disciplinary action;
Communicating information security incident details to internal and external people or organisation's.
This may include communicating with several types of outside parties such as other incident response
teams, information sharing organisation's, internet service providers, software and support vendors,
law enforcement agencies, customers, media and other relevant parties. All contacts and
communications with outside parties should be documented for liability and evidentiary purposes.

Trust and Confidence

he IRT plays a crucial role for the overall information security of an organisation. The IRT requires the collaboration of all organisation.a
ust within the organisation. is created by fiat and stems from the support given by the top management, i.e. the trust is given. External e

Work to educate users (internal and external), explain how the IRT works, how it protects
confidentiality of information collected and how it manages security event, incident and vulnerability
reports.
 Document and publicise provisions that clearly illustrate the expectation of anonymity, or lack thereof,
for persons or parties reporting a suspected information security incident or vulnerability.
The IRT should be capable of efficiently satisfying the functional, financial, legal and political needs of
the organisation. and be able to exercise organisational discretion when managing information
security incidents and vulnerabilities.

Act independently and audited to confirm that all business requirements are being satisfied effectively.

Achieve independence by separation of the incident and vulnerability reporting chain from operational
line management and to make a top manager directly responsible for managing incident and
vulnerability responses.

Is the IRT finance capability separate from the vulnerability reporting function.

Handling confidential or sensitive information

n information security incident management plan may contain sensitive information and people involved in addressing incidents and vu
equired (e.g. when leaving the protective domain of the IRT). If information security events/incidents/vulnerabilities are logged via a gen
mitted information, this can lead to a situation where the IRT will maintain its own information security database.

Does the information security incident management plan makes provision for controlling the
communication of incidents and vulnerabilities to external parties, including the media, business
partners, customers, law enforcement organisation's, and the general public.

Establishing an incident response team (IRT).

ts entirety, links to ISO/IEC 27035-1:2016, 5.2 d).
Establishing relationships with other organisation's
ts entirety, links to ISO/IEC 27035-1:2016, 5.2 e).
Defining technical and other support
ts entirety, links to ISO/IEC 27035-1:2016, 5.2 f).
Creating information security incident awareness and training
its entirety, links to ISO/IEC 27035-1:2016, 5.2 g).
Testing the information security incident management plan
its entirety, links to ISO/IEC 27035-1:2016, 5.2 h.
Lessons learned
its entirety, links to ISO/IEC 27035-1:2016, 5.6.
 Observation

d principles and intentions used to direct decision-making and ensure consistent and appropriate implementation of processes, procedu
mission of its parent organisation. and be in line with already existing policies and procedures. An organisation. should implement an in
cidents) when an information security incident occurs. The policy should be reviewed regularly to ensure it reflects the latest organisation
nt response (see Clause 10). The following pre-requisites have been set:

Observation

enterprise-wide process. To that end, all stakeholders or their representatives should be involved in the development of the policy from

Observation

-by-step instructions should be included in the series of documents that make up the information security incident management plan, wh

Observation
rity policies at corporate level, as well as on specific system, service and network levels and relate this content to the incident managem
 Observation

icies, and specific system, service or network information security policies in tandem to ensure they remain consistent and current. Thes
propriate review mechanisms need to be established. These review mechanisms need to ensure that information from the detection, mo
veness of the policies.

Observation

es for dealing with information security events, incidents and vulnerabilities, and communication of them. The plan stems from and is ba
lements and support tools for the detection and reporting of, assessment and decision making related to, responses to and learning les
mponents of the plan. These components will provide the step-by-step instructions for incident handlers to follow using specific tools, foll
is detected or information security vulnerability is reported. An organisation. should use the plan as a guide for the following:

Observation

nt policy. However, where there is no guiding policy or standard, prevailing law, or other authoritative source, the incident management
ed between IRT members and partner organisation's. This includes names and identifiers for organisation's and teams, information ass
 ed between IRT members and partner organisation's. This includes names and identifiers for organisation's and teams, information ass

Observation

by all personnel and associated contractors, ICT service providers, telecommunication providers and outsourcing companies.
Observation

and reviewed before the planning and preparation process considers specific incident types and the corresponding response processe

pecifying detailed activities. As noted above, the plan documentation should encompass multiple documents including the forms, proced

Observation
ny event, the decision should be based on the actual or projected adverse impacts on the organisation's business operations.

Observation

orms should be determined by the IRT and revised periodically to ensure their relevance. An additional form type that allows for descript
Observation
portant that an organisation. has documented and checked that necessary processes and procedures are available.
Observation

ollaboration of all organisation.al personnel to detect, resolve and investigate information security incidents. It is fundamental that the IR
i.e. the trust is given. External entities that have to deal with the IRT (e.g. IRTs from other organisation's) need to be confident that the

Observation
d in addressing incidents and vulnerabilities may be required to handle sensitive information. An organisation. should ensure that the ne
nerabilities are logged via a generalised problem management system where it is not possible to restrict who has access to it, sensitive
atabase.
Observation
 Recommendation

edures, etc. with regard to this policy. Any information security incident management policy
n information security incident management policy that outlines the processes, responsible
ation.al structure, processes, and technology that can affect incident response. The policy

Recommendation

rom the initial planning stages through the implementation of any process or response team.

Recommendation

, which is outlined in Clause 6. An organisation. should ensure that its information security

Recommendation
gement policy. The integration should aim for the following:
 Recommendation

These corporate-level policies should refer explicitly to the information security incident
, monitoring and resolution of information security incidents and from dealing with reported

Recommendation

based on the information security incident management policy. Overall, the plan
lessons from information security incidents. The plan may include a high level outline of the
following specific workflows or handling specific types of incidents based on the situation. The

Recommendation

ent planning process should be based on consensus to ensure effective operation,

assets, business processes, etc. Where terminology is difficult or prone to misinterpretation, the
assets, business processes, etc. Where terminology is difficult or prone to misinterpretation, the

Recommendation

Recommendation

sses. This requires available policy, formal or informal understanding of assets and controls,

cedures, organisation.al elements and support tools.

Recommendation
 Recommendation

riptive text should exist. Its purpose is to provide mechanism to capture information in instances
Recommendation
 Recommendation

e IRT is trusted by the whole organisation. and that external entities have confidence in it. The
the IRT will perform its job professionally, i.e. the trust should be earned. Does the IRT:

Recommendation
e necessary processes and capabilities are established to anonymise sensitive information when
ive details may have to be omitted. Give that the IRT would still have to have access to the

Recommendation
The following standards have been provided for further support on incident response management.

ISO Standard Objective

ISO/IEC 27037 Guidelines for the identification, collection, acquisition and
preservation of digital evidence.

ISO/IEC 27038 Specification for digital redaction

ISO/IEC 27040 Storage security

ISO/IEC 27041 Guidance on assuring the suitability and adequacy of

incident investigation methods

ISO/IEC 27042 Guidelines for the analysis and interpretation of digital

evidence.

ISO/IEC 27043 Incident investigation principles and processes

ISO/IEC 27050 Electronic discovery

ISO/IEC 30121 Governance of digital forensic risk framework

incident response management.

Definition
This standard describes the means by which those involved in the early stages of an investigation, including initial response
evidence is captured to allow the investigation to proceed appropriately.

Some documents can contain information that should not be disclosed to some communities. Modified documents can be re
processing of the original document. The process of removing information that is not to be disclosed is called “redaction”.

The digital redaction of documents is a relatively new area of document management practice, raising unique issues and po
redacted, removed information should not be recoverable. Hence, care needs to be taken so that redacted information is pe
it should not be simply hidden within non-displayable portions of the document).

ISO/IEC 27038 specifies methods for digital redaction of digital documents. It also specifies requirements for software that c

ISO/IEC 27040 provides detailed technical guidance on how organisations can define an appropriate level of risk mitigation
approach to the planning, design, documentation and implementation of data storage security. Storage security applies to th
stored and to the security of the information being transferred across the communication links associated with storage. Stor
media, the security of management activities related to the devices and media, the security of applications and services, an
of devices and media and after end of use.

Security mechanisms like encryption and sanitisation can affect one’s ability to investigate by introducing obfuscation mech
during the conduct of an investigation. They can also be important in ensuring that storage of evidential material during and
secured.

It is important that methods and processes deployed during an investigation can be shown to be appropriate. This documen
that methods and processes meet the requirements of the investigation and have been appropriately tested.

This standard describes how methods and processes to be used during an investigation can be designed and implemented
digital evidence, interpretation of digital evidence and effective reporting of findings.

This standard defines the key common principles and processes underlying the investigation of incidents and provides a fra

ISO/IEC 27050 addresses activities in electronic discovery, including, but not limited to identification, preservation, collectio
Electronically Stored Information (ESI). In addition, it provides guidance on measures, spanning from initial creation of ESI t
can undertake to mitigate risk and expense should electronic discovery become an issue. It is relevant to both non-technica
the electronic discovery activities. It is important to note that this guidance is not intended to contradict or supersede local ju

Electronic discovery often serves as a driver for investigations as well as evidence acquisition and handling activities. In add
sometime necessitate protections like storage security to guard against data breaches.

ISO/IEC 30121 provides a framework for governing bodies of organisations (including owners, board members, directors, p
way to prepare an organisation for digital investigations before they occur. ISO/IEC 30121 applies to the development of str
retention, availability, access and cost effectiveness of digital evidence disclosure.

ISO/IEC 30121 is applicable to all types and sizes of organisations. ISO/IEC 30121 is about the prudent strategic preparatio
Forensic readiness assures that an organisation has made the appropriate and relevant strategic preparation for accepting
can occur as the result of inevitable security breaches, fraud, and reputation assertion. In every situation Information Techn
maximise the effectiveness of evidential availability, accessibility and cost efficiency.
 Glossary
The following terms and definitions are used within the ISO27035 standard and a

Abbreviation Term
CD Compact disk
CERT Computer Emergency Response Team
CSIRT Computer Security Incident Response Team
DNS Domain name system
DVD Digital versatile disk
ICMP Internet control message protocol
IDS Intrusion detection system
IPv4 Internet protocol v4
IPv6 Internet protocol v6
ISP Internet service provider
Information security investigation
IRT Incident response team

Information security event

Information security incident

Information security incident management

Incident handling
Incident response

PoC Point of contact

SMTP Simple mail transfer protocol

SSL Secure sockets layer protocol
TCP Transmission control protocol
TLP Traffic light protocol
TLS Transport layer security protocol
UDP User datagram protocol
Wi-Fi Wi-Fi wireless fidelity
 Glossary
nd definitions are used within the ISO27035 standard and are captured here to assist in understanding.

Definition

commonly used terms for IR

commonly used terms for IR

Application of examinations, analysis and interpretation to aid understanding of an information security incident
team of appropriately skilled and trusted members of the organisation that handles incidents during their lifecycle

occurrence indicating a possible breach of information security or failure of controls

one or multiple related and identified information security events that can harm an organisation’s assets or compromise its
operations
exercise of a consistent and effective approach to the handling of information security incidents
actions of detecting, reporting, assessing, responding to, dealing with, and learning from information security incidents
actions taken to mitigate or resolve an information security incident (3.4), including those taken to protect and restore the
normal operational conditions of an information system and the information stored in it.
defined organisational function or role serving as the coordinator or focal point of information
concerning incident management activities
Document Record

Date By
7/19/2019 NCC Group
Comment
Document Issue