Learn by Doing: Practical guide

About the author

Noureddine Kanzari is a cybersecurity expert with an extensive background in IT risk

management and cybersecurity instruction. With a diverse range of certifications that includes
being a PECB Certified Trainer, DORA Senior Lead Manager, NIST Cybersecurity Consultant,
Senior Lead Incident Manager, Senior Lead SOC 2 Analyst, Data Protection Officer (DPO),
DORA Senior Lead Manager, ISO 42001 Senior Lead Auditor, ISO 42001 Senior Lead
Implementer, Senior Lead SCADA Security Manager, ISO 22301 Senior Lead Implementer,
ISO 22301 Senior Lead Auditor,EBIOS Risk Manager, ISO 27005 Senior Lead Risk Manager,
ISO 27001 Senior Lead Implementer, ISO 27001 Senior Lead Auditor, Cisco Certified
Specialist in Security Core and Enterprise Core, NSE4 Network Security Professional, Palo
Alto Instructor, Devops Tools Engineer, LPIC-3 Enterprise Professional Security, LPIC-3
Enterprise Professional Virtualization & High Availability, LPIC-2, LPIC-1, Suse Certified Linux
Administration, and a Certified Security Auditor in computer security,
Noureddine Kanzari's professional journey is characterized by a series of impactful roles and
accomplishments. Throughout his career, he has held various pivotal positions, including:
Chief Information Security Officer (CISO)
Audit Team Leader
Cybersecurity Instructor
Technical Manager
Training Manager
His extensive experience and leadership have contributed significantly to enhancing
cybersecurity practices, risk management strategies, and organizational resilience.

2
 Contents

1. ORGANIZATIONAL CONTROLS ............................................................................................ 4

1.1 Acceptable use of information and other associated assets (5.16) ..................................... 4

1.2 Practical Application of Clause 5.16: Case Study: ”Tech Solutions” ................................... 6

1.3 Authentication information (5.17) ...................................................................................... 14

1.4 Practical Application of Clause 5.17: Case Study: ”Tech Solutions” ................................. 17

1.5 Access rights (5.18) .......................................................................................................... 26

1.6 Practical Application of Clause 5.18: Case Study: ”Tech Solutions” ................................. 29

1.7 Information security in supplier relationships (5.19) .......................................................... 41

1.8 Practical Application of Clause 5.19: Case Study: ”Tech Solutions” ................................. 44

1.9 Addressing information security within supplier agreements (5.20) .................................. 66

1.10 Practical Application of Clause 5.20: Case Study: ”Tech Solutions” ............................... 69

3
1. ORGANIZATIONAL CONTROLS

1.1 Acceptable use of information and other associated assets (5.16)

Control 5.16:
The full life cycle of identities should be managed.

Control attributes:
 Control type: When it acts : Preventive
 Information security properties: Confidentiality, Integrity, Availability
 Cybersecurity concepts: Which phase of cybersecurity it supports : Protect
 Optional capabilities: Which operational area it belongs to : Identity_and_access_management
 Security domains: Which domain it relates to : Protection

Information security Cybersecurity

Control type Optional capabilities Security domains
properties concepts

Confidentiality Identity_and_ac-
Préventive Integrity Protect Protection
Availability cess_management

Control description:
 Identity management, which is about controlling and securing the identities (like user
accounts)
 Each person should have their own unique identity (like a username or account) in the
system, so that any actions they take (e.g., accessing files, making changes) can be
traced back to them. This ensures accountability.
 Sometimes, multiple people might share one identity (e.g., a generic “Admin” account).
This is only allowed if there’s a valid business or operational reason (e.g., a team needs
a shared account for a specific task). These shared accounts need special approval and
must be documented properly.
 Identities assigned to non-human entities (like software, bots, or devices) must be
managed carefully. These identities need separate approval processes and ongoing
monitoring
 If an identity is no longer needed (e.g., an employee leaves the company, changes
roles, or a device is decommissioned), it should be disabled or deleted promptly.

4
  If an identity is no longer needed (e.g., an employee leaves the company, changes
roles, or a device is decommissioned), it should be disabled or deleted promptly.
 Within a specific system or domain, one entity (person, device, etc.) should only have
one identity.
 The organization must keep logs of important events related to identities, such as:
o Creating or deleting accounts.
o Changing permissions.
These records help track who did what and when, which is useful for audits or
investigating security incidents.
 The goal is to: Make sure every action can be linked to a specific person or entity.

Control evidence:

Checks to be performed Evidence

 If an identity management process is defined,
documented and implemented
 Whether the identities assigned to people are
unique
 If the use of shared identifiers is only allowed
when necessary
 If unused identities are deactivated or deleted
 Access management procedure.
 Whether events related to identity
management and authentication information
are retained
 If an access management procedure is
defined and implemented
 Whether redundant user IDs are periodically
identified and removed or disabled.

5
1.2 Practical Application of Clause 5.16: Case Study: ”Tech Solutions”

6
7
8
9
10
11
12
13
1.3 Authentication information (5.17)
Control 5.17:
Allocation and management of authentication information should be controlled by a
management process, including advising personnel on the appropriate handling of
authentication information.
Control attributes:
 Control type: When it acts : Preventive
 Information security properties: Confidentiality, Integrity, Availability
 Cybersecurity concepts: Which phase of cybersecurity it supports : Protect
 Optional capabilities: Which operational area it belongs to : Identity_and_access_management
 Security domains: Which domain it relates to : Protection

Information security Cybersecurity

Control type Optional capabilities Security domains
properties concepts

Confidentiality Identity_and_ac-
Préventive Integrity Protect Protection
Availability cess_management

Control description:
 How organizations should create, distribute, and manage passwords or PINs securely.
 When a new user is set up (e.g., during account creation), any temporary password or
PIN generated automatically should be random and unique for each person.
 Users must change this temporary password the first time they log in.
 Before giving someone a new password, temporary password, or replacement, the
organization must confirm they are who they claim to be (e.g., through ID checks or
security questions).
 Passwords or PINs should be sent to users through secure methods (e.g., encrypted
emails or secure apps), not through regular, unprotected emails.
 Users should acknowledge (e.g., via a reply or clicking a confirmation link) that they’ve
received their password.
 Systems or software often come with default passwords set by the vendor (e.g., “admin”
or “password”). These must be changed as soon as the system is installed.
 The organization should log important actions (e.g., issuing or changing passwords)
and store these records securely, using approved tools like a password vault.

14
 Users must not share their personal passwords with anyone.
 For shared accounts (e.g., a team account), passwords should only be shared with
authorized people.
 If a user suspects their password has been stolen or compromised (e.g., after a
phishing attack), they must change it right away.
 Passwords should follow these best practices:
o Don’t use personal info like names, birthdays, or phone numbers (e.g., avoid
“John1985”).
o Avoid dictionary words like “apple” or “house” (or combinations like
“applehouse”).
o Use passphrases (e.g., “SunnyHill2023!”) with letters, numbers, and special
characters.
o Ensure minimum length (usually 12+ characters for better security).
 Don’t reuse the same password across multiple services or systems
 The system should allow users to pick their own passwords and change them when
needed.
 The system must ensure users create strong passwords
 When a user logs in for the first time (e.g., with a temporary password), the system
must require them to set a new password.
 The system should stop users from reusing passwords they’ve used before.
 When users type their password, it should appear as dots or asterisks (e.g., ****)
instead of plain text.
 Passwords should be stored and sent using encryption or hashing (approved
cryptographic methods) to protect them.

15
Control evidence:

Checks to be performed Evidence

 Whether a formal management process is
implemented for the allocation of secret
authentication information
 Whether users are required to sign an
 Document of the process for
undertaking to keep secret authentication
assigning secret authentication
information confidential
information
 Whether temporary secret authentication
 Sample confidentiality commitments
information is provided to users securely
 Sample Acknowledgments of Secret
 If users sign an acknowledgment of receipt of
Authentication Information
secret authentication information
 If the default secret authentication information
of the system or software vendors is changed
after installation

16
1.4 Practical Application of Clause 5.17: Case Study: ”Tech Solutions”

17
18
19
20
21
22
23
24
25
1.5 Access rights (5.18)
Control 5.18:
Access rights to information and other associated assets should be provisioned, reviewed,
modified and removed in accordance with the organization’s topic-specific policy on and rules
for access control.

Control attributes:
 Control type: When it acts : Preventive
 Information security properties: Confidentiality, Integrity, Availability
 Cybersecurity concepts: Which phase of cybersecurity it supports : Protect
 Optional capabilities: Which operational area it belongs to : Identity_and_access_management
 Security domains: Which domain it relates to : Protection

Information security Cybersecurity

Control type Optional capabilities Security domains
properties concepts

Confidentiality Identity_and_ac-
Préventive Integrity Protect Protection
Availability cess_management

Control description:
 How to grant or remove access to systems, data, or physical spaces in a secure way.
 Before giving someone access to information or assets (like files, databases, or
equipment), you need approval from the person responsible for those assets. (Example:
If someone needs access to a customer database, the database owner must approve
it.)
 Access should only be given based on what the person needs to do their job (Example:
A salesperson might need access to customer data but not to financial records)
 Ensure that the person approving access is different from the person setting it up
(segregation of duties). (Example: The manager who approves access shouldn’t be the
one configuring the user’s account.)
 Take away access rights when someone no longer needs them, especially if they leave
the organization
 For temporary workers or short-term tasks, give access only for a specific time period.

26
 Make sure the level of access given follows the organization’s access control policies
(Example: An employee shouldn’t have admin-level access if their job only requires
basic user access)
 Access should only be turned on (e.g., by IT or a service provider) after all approvals
are complete.
 Maintain a central list of who has access to what (e.g., a database)
 A spreadsheet or system that lists each user’s ID and what systems they can access.
 If someone changes jobs or roles within the organization, adjust their access to match
their new responsibilities.
 When access is no longer needed, remove or change it by taking away keys,
passwords, ID cards, or system subscriptions.( Example: If someone’s role changes,
their old password or keycard should be deactivated.)
 Keep a record of any changes made to access rights, like when access is granted,
changed, or removed.( Example: Log every time an employee’s access is updated in a
secure system.)
 Pay special attention to users with high-level access (like admins who can change
systems). (Example: Check if an IT admin still needs full system access or if it can be
reduced.)
 If someone is fired, their access should be revoked immediately to prevent retaliation.
 If an employee no longer works on a project, their access to related files should be
removed.

27
Control evidence:

Checks to be performed Evidence

 If a process for provisioning or revoking
physical and logical access rights granted to
an entity's authenticated identity is
implemented
 If the authorization of the owner of the
information and other associated assets, for
the use of this information and other
associated assets, is obtained
 Whether the level of access granted complies
with the access control policy and is
compatible with other requirements such as
separation of duties
 Whether a record of the access rights granted
to a user, to access information and other  Access control policy
associated assets, is maintained
 Access rights matrix
 Whether the access rights of users who have
changed roles or jobs are updated and
whether the access rights of users who have
left the organization are removed or blocked
immediately
 Whether user access rights are reviewed at
regular intervals and after any changes
 If user access rights are reviewed and
reassigned when roles within the organization
change
 Whether permissions for privileged access
rights are reviewed at more frequent intervals

28
1.6 Practical Application of Clause 5.18: Case Study: ”Tech Solutions”

29
30
31
32
33
34
35
36
37
38
39
40
1.7 Information security in supplier relationships (5.19)
Control 5.19:
Processes and procedures should be defined and implemented to manage the information
security risks associated with the use of supplier’s products or services.

Control attributes:
 Control type: When it acts : Preventive
 Information security properties: Confidentiality, Integrity, Availability
 Cybersecurity concepts: Which phase of cybersecurity it supports : Protect
 Optional capabilities: Which operational area it belongs to : Supplier_relation-ships_security
 Security domains: Which domain it relates to : Governance_and_Ecosystem, Protection

Information security Cybersecurity

Control type Optional capabilities Security domains
properties concepts

Governance_and_
Confidentiality Supplier_relation-
Préventive Integrity Identity Ecosystem, Protec-
Availability ships_security
tion

Control description:
 The organization must create a clear policy on how to work securely with suppliers
 This includes setting up processes to identify and manage risks related to the products,
services, or resources (like cloud services) provided by suppliers.
 Write a specific policy about how the organization works with suppliers
 Share this policy with everyone who needs to know (e.g., employees, suppliers).
 The policy should explain how to keep information secure when using supplier products
or services.
 List the kinds of suppliers you work with (e.g., IT services, logistics, utilities, banks).
 Note which suppliers could impact the confidentiality (keeping info private), integrity
(ensuring info is accurate), or availability (ensuring info is accessible) of your
organization’s information.
 Evaluate suppliers

41
 Review the security measures suppliers use to protect their own systems and your
information.
 Make sure their controls are accurate and complete to maintain the integrity of their
services and your data.
 Clearly state which parts of your organization’s information, IT systems, or physical
locations (e.g., offices, data centers) suppliers can access, monitor, or control.
 Identify Risky Supplier Components: Pinpoint which supplier-provided IT components or
services could affect your information’s confidentiality, integrity, or availability (e.g.,
software, hardware, or cloud storage).
 Look for risks like: Malicious supplier employees accessing your data.
 Create plans to reduce these risks.
 Monitor Supplier Compliance: Regularly check if suppliers follow your security
requirements.
 Handle Non-Compliance: If a supplier doesn’t meet security standards, take action to fix
the issue (e.g., work with them to improve or switch suppliers).
 Manage Incidents: Have a plan for handling problems with supplier products or services
(e.g., a software failure or data breach).
 Define who (you or the supplier) is responsible for fixing issues.
 When stopping work with a supplier, ensure: Their access to your systems is removed.
 Plan for Supplier Failure: Have backup plans, like identifying alternative suppliers in
advance, to avoid delays.

42
Control evidence:

Checks to be performed Evidence

 If a policy identifying and imposing specific
security measures on supplier access to
assets
 Whether processes and procedures to
address security risks associated with the use
of vendor products and services are identified
 Policy identifying and imposing
 Whether the types of suppliers to whom the
specific security measures on
organization will grant access to its
supplier access to assets
information are identified and documented
 List of supplier types (e.g. IT
 Whether the supplier evaluation and selection
services, logistics services, financial
criteria are defined and documented
services)
 If we contractually impose on any supplier
 Commitments to respect security
who may have access to sensitive
clauses signed by the supplier's
information, compliance with security clauses
employees
 If an analysis of the risks linked to access by
 Risk analysis report relating to
the supplier's personnel to the information
access by supplier personnel
system or to premises containing information
is carried out and if the necessary security  List of types of access to information
measures are defined accordingly granted to different types of suppliers
 Whether the types of access to information  Incident processing report and
that different types of suppliers will be granted associated supplier access
are defined and whether this access is
monitored and controlled
 Whether incidents associated with supplier
access, including the responsibilities of the
organization and those of the suppliers, are
identified and addressed

43
1.8 Practical Application of Clause 5.19: Case Study: ”Tech Solutions”

44
45
46
47
48
49
50
51
52
53
54
55
56
59
60
61
62
63
64
65
1.9 Addressing information security within supplier agreements (5.20)
Control 5.20:
Relevant information security requirements should be established and agreed with each
supplier based on the type of supplier relationship.

Control attributes:
 Control type: When it acts : Preventive
 Information security properties: Confidentiality, Integrity, Availability
 Cybersecurity concepts: Which phase of cybersecurity it supports : Protect
 Optional capabilities: Which operational area it belongs to : Supplier_relation-ships_security
 Security domains: Which domain it relates to : Governance_and_Ecosystem, Protection

Information security Cybersecurity

Control type Optional capabilities Security domains
properties concepts

Governance_and_
Confidentiality Supplier_relation-
Préventive Integrity Identity Ecosystem, Protec-
Availability ships_security
tion

Control description:
 Describe what information the supplier will access or receive (e.g., customer data,
financial records).
 Specify how this information will be shared or accessed (e.g., via email, cloud platform,
or physical documents)
 List all laws, regulations, and contracts the supplier must follow (e.g., data protection
laws like GDPR, intellectual property rules).
 Explain how the supplier will comply with these requirements. (Example: If handling
personal data, the supplier must follow privacy laws and prove compliance.)
 The supplier must follow your organization’s security policies (Example: Require the
supplier to use strong passwords and report security incidents.)
 Define acceptable and unacceptable ways to use the information or assets (Example: A
supplier can’t share your data with others without permission.)

66
 Set minimum security standards for the supplier’s IT systems based on the type of
information and access (Example: Require encryption for sensitive data stored on their
servers.)
 Include terms for compensation or fixes if the supplier fails to meet security
requirements. (Example: If a breach occurs due to their negligence, they cover the
costs.)
 Define how the supplier should handle security incidents (Example: If there’s a data
breach, they must report it immediately and work with you to resolve it.)
 Require the supplier to train their staff on your security policies and procedures.
(Example: Train their team on how to spot phishing emails.)
 Name a specific person at the supplier’s organization for security-related questions or
issues.
 Where legally allowed, require background checks for supplier employees handling your
information (Example: Ensure their staff are vetted before accessing sensitive data.)
 Ask for evidence (e.g., certifications, audit reports) that the supplier meets security
standards. (Example: Request a SOC 2 report to verify their security controls.)
 Reserve the right to audit the supplier’s processes and controls to ensure compliance.
(Example: Conduct annual checks of their security practices.)
 Require the supplier to provide periodic reports on their security controls and fix any
issues quickly. (Example: Submit a quarterly report on firewall performance.)
 Define processes for fixing problems (e.g., bugs in their system)
 Ensure the supplier backs up your data according to your needs (e.g., frequency,
storage location). (Example: Daily backups stored in a secure, offsite location.)
 Require the supplier to notify you of changes (e.g., system updates) and allow you to
reject them if needed. (Example: Inform you before upgrading software that handles
your data.)
 Include terms for ending the contract, such as returning assets, securely disposing of
data, and maintaining confidentiality afterward. (Example: Return all customer data and
destroy copies when the contract ends.)
 Ensure the supplier securely deletes your information when it’s no longer needed.
(Example: Shred physical documents or wipe digital data permanently.)


67
Control evidence:

Checks to be performed Evidence

 If an agreement signed with a third party
involving access to the information system or
to the premises containing information is
defined and documented
 Whether agreements with suppliers contain
compliance with all information security
requirements (including description and
classification of information, methods of
accessing information and rules for
acceptable use of information
 Whether agreements with suppliers contain
legal, statutory, regulatory and contractual
requirements, including data protection,  Document defining all the security
processing of personal data (PD), intellectual clauses that any agreement signed
property rights and copyright with a third party should include
 Whether agreements with suppliers contain
incident management requirements (in
particular notification and collaboration during
corrective action)
 Whether the agreements with suppliers
contain security measures for the transfer of
information
 If any access by a third party to the
information system or to the premises
containing information is only authorized after
the signing of a formal agreement containing
these clauses.

68
1.10 Practical Application of Clause 5.20: Case Study: ”Tech Solutions”

69
70
71
72
73
74
75
76