Tidal Control

Rules and procedures have been defined and implemented to continue and recover business services, and to limit losses, in the event of severe business disruption.

Evidence

• Business continuity framework

Further guidance

The business continuity framework should include:

• a policy statement
• procedure for performing a business impact analysis (BIA)
• rules for performing continuity risk assessments
• procedure to respond to incidents and communicate in the event of a crisis
• contracted RPO, RTO, and up-time for critical business services
• disaster recovery scenarios and dependencies

Risk treatment plans identify all controls needed to implement the chosen information security risk treatment.

Evidence

• Statement of Applicability

Further guidance

Specific requirement for ISO 27001:
A Statement of Applicability has been established which contains:

• all necessary controls,
• justification for their inclusion;
• whether the necessary controls are implemented or not
• justification for excluding any of the ISO 27001 Annex A controls.

Access control procedures are in place defining how access is managed, who is allowed to access what and how, and which authentication methods and requirements apply where.

Evidence

• Access control policy

Code linters are configured as part of the release pipeline.

Evidence

• Code linter configuration for release pipeline(s)

Further guidance

Code linter: A tool that programmatically scans source code with the goal of finding issues that can lead to bugs or inconsistencies with code health and style. Code linters are commonly able to flag programming errors, bugs, stylistic errors, and suspicious constructs.

Agreements (contracts and service level agreements) with third parties include organisation's risk assessment and requirements.

Evidence

• Contracts with third parties

Operating Procedures are in place for operational activities associated with information security.

Evidence

• Operating procedures for IT management

Further guidance

Procedures need to be in place for activities that meet the following requirements:

• the activity needs to be performed in the same way by many people or be able to be handed over to someone else;
• the activity is new or performed rarely and presents a risk if not performed correctly;

Documented operating procedures should be reviewed and updated when needed, and changes authorised.

Examples of relevant operational activities:

• How to install and configure systems
• How to process or handle certain information
• How to perform backups and restores
• How to manage scheduling inter-dependencies between systems
• How to handle errors or other exceptional conditions
• How to ask for external support and escalate unexpected technical difficulties
• How to handle storage media
• How to restart systems or services
• How to handle audit trails and system logs
• How to monitor services for capacity, performance, and security
• How to maintain systems, networks, and applications

Static code analysis is configured as part of the release pipeline.

Evidence

• Configuration of release pipeline
• Review of releases that do not pass the static code quality gate

Further guidance

Static Code Analysis: A white box test, commonly referring to the running of Static Application Security Testing (SAST) tools that attempt to highlight possible vulnerabilities within ‘static’ (non-running) source code by using techniques such as Taint Analysis and Data Flow Analysis. SAST does not require code to be compiled, and can hence be applied in the code development stage.

Data at rest is appropriately encrypted to ensure the integrity and confidentiality of the data.

Evidence

• Review of encryption configuration for data at rest

Third party access to our networks, systems, and other services is removed when supplier contracts end.

Evidence

• Evidence of removal of third party access

All (internal and external) software developers working for the organisation acknowledge their understanding and compliance with the secure development framework.

Evidence

• Acknowledgement of Secure development framework

Data in transit is appropriately encrypted to ensure the integrity and confidentiality of the data.

Evidence

• Evidence to determine strength of encryption configuration for data in transit

All individuals departing from employment, including key function holders, undergo a comprehensive exit process. This process includes returning company assets.

Evidence

• Evidence of return of assets by Leavers

All individuals becoming employees, including key function holders, are screened prior to them performing activities subject to screening.

Evidence

• Results of employee screening

Development, testing and operational environments are logically or physically separated to reduce the risks of unauthorized access or changes to the operational environment and to ensure no impact to production systems.

Evidence

• Evidence of separation of development, testing and production environments

Endpoints are adequately protected and the use of these devices is authorised by management.

Evidence

• Endpoint configuration and handling policy

Further guidance

Endpoint: Any device which stores or processed information (e.g. laptops, mobile devices) whether owned by the organization or owned privately and used on behalf of the organization [bring your own device (BYOD)].

Rules and procedures have been established to produce logfiles of activities, exceptions, faults and other relevant (information security) events.

Evidence

• Event logging policy

Rules and procedures are defined and implemented to classify data and assets according to the sensitivity and type of data.

Evidence

• Information classification policy

An internal audit function has been established. The function is tasked with assessing compliance with relevant statutory, regulatory and contractual controls, and the effectiveness of the compliance function.

Evidence

• Internal audit framework

Non-disclosure agreements are in place with all suppliers that have access to classified and other restricted information.

Evidence

• Non-disclosure agreements (NDAs) with relevant third parties

Further guidance

The information classification policy and business impact analysis (BIA) provide more details on which information is considered restricted.

Penetration tests and other security verification tests should be performed on a regular basis. Software security testing can be performed as part of a specific release, or as part of a wider information security test.

Evidence

• Penetration test report

Clear roles and responsibilities, including mandates and reporting lines, to identify, implement and manage the organisation's strategy, policies, and relevant statutory, regulatory and contractual controls are defined and assigned.

Evidence

• Records of skills, experience and qualifications for employees with specific roles regarding information security

Internal and external risks that the organisation is exposed to are identified, assessed, reported and documented.

Evidence

• Risk assessment report(s)

Determine the boundaries and applicability of the information security management system.

Evidence

• Scope of the ISMS

Sensitive and/or personal data is masked or sanitised where possible in line with applicable regulations.

Evidence

• Review of information assets to determine the need for masking
• (if applicable) Evidence of masking

Information security risk assessments are performed for suppliers where risks are associated with the use of their products or services.

Evidence

• Supplier risk assessment(s)

Further guidance

A risk assessment should be performed prior to starting the cooperation, and when the risk profile changes (e.g. due to procuring additional services from the supplier)

Protection against malware is in place to detect and eradicate malicious code.

Evidence

• Evidence of installed anti-malware software

Networks and network devices are secured, managed and controlled to protect information in systems and applications. This includes the logical or physical segmentation of information flows.

Evidence

• Network architecture overview
• Evidence of (virtual) segmentation of information flows

Business impact analyses (BIAs) are performed periodically to determine the maximum tolerable downtime for each critical function and identify dependencies between functions.

Evidence

• Business impact analysis

Data is retained for a defined period of time to fulfill the identified purpose or as required by law, and is securely disposed of at the end of this period.

Evidence

• Configuration of data retention for storage systems
• Evidence of deletion of data that is no longer required

Further guidance

The records management policy specifies the rules for retaining and/or disposing of data.

When setting system-specific retention policies for data, we should evaluate:

1. Regulatory requirements to retain and/or dispose of data after a certain time
2. Requirements following from the data classification
3. The principle of data minimisation, i.e. to dispose of data when it has no further value for the organisation.

Data should be disposed of, destroyed or erased in a secure way.

Data disposal should include all originals, copies and archived records of the data.

Data protection Agreements (DPA) are included in supplier contracts in line with GDPR requirements.

Evidence

• Data protection agreements with third parties

Rules for the effective use of cryptography, including cryptographic key management, are defined and implemented.

Evidence

• Encryption policy

An incident register has been established. Each incident is registered in the incident register, and categorised and prioritised for analysis and resolution.

Evidence

• Incident register

Incidents are communicated and reported adequately and in a timely manner. Where relevant, incident root causes are identified and lessons learned are implemented to prevent similar incidents in the future.

Evidence

• Evidence of adequate and timely reporting of significant and disruptive incidents

Further guidance

• Significant and disruptive incidents are reported with undue delay to management and external bodies in accordance with applicable laws and regulations.
• Root causes and lessons learned are identified where applicable to prevent similar incidents in the future.

Procedures and responsibilities are in place to identify, track, log, categorise, and classify incidents according to a priority, based on business criticality.

Evidence

• Incident response framework

All individuals becoming employees, including key function holders, sign confidentiality or non-disclosure agreements reflecting the organization’s needs for the protection of information.

Evidence

• Non -disclosure agreements (NDAs)

Capacity and performance of systems, applications and services are continuously monitored to ensure meeting expected and anticipated future capacity requirements.

Evidence

• Evidence of monitoring (and if needed - adjusting) of resource usage

The restore of information from a backup is periodically tested and evaluated against RPO and RTO targets.

Evidence

• Report of test of restore procedure

Risks are mitigated to an acceptable level by regularly assessing appropriate information security risk treatment options, and identifying and implementing appropriate mitigating controls.

Evidence

• Risk Treatment Plan(s)

Clear roles and responsibilities, including mandates and reporting lines, to identify, implement and manage the organisation's strategy, policies, and relevant statutory, regulatory and contractual controls are defined and assigned.

Evidence

• Definition of security roles & responsibilities

Logfiles of activities, exceptions, faults and other relevant (information security) events are produced, stored, and analysed. Appropriate actions are taken to evaluate potential information security incidents.

Evidence

• Configuration of security information and event management (SIEM) solution
• Evidence of review of events reported by the SIEM solution used

Legal, statutory, regulatory and contractual requirements relevant to information security and the organization’s approach to meet these requirements should be identified, documented and kept up to date.

Evidence

• Statutory, regulatory, and contractual requirements

Endpoints are adequately protected and the use of these devices is authorised by management.

Evidence

• All employee endpoints are registered in the asset inventory and enrolled in our mobile device management (MDM) solution

Further guidance

Endpoint: Any device which stores or processed information (e.g. laptops, mobile devices) whether owned by the organization or owned privately and used on behalf of the organization [bring your own device (BYOD)].

Backups of data, software and/or system images are created periodically to ensure the availability of the data to satisfying Recovery Time Objectives (RTOs) and Recovery Point Objectives (RPOs).

Evidence

• Evidence of backup configuration
• Log of backups performed

Software and firmware are kept up to date by deploying critical security patches and application updates in a timely manner.

Evidence

• Evidence of implementation of critical security patches / applicable patch levels
• Overview of active security concerns/unpatched vulnerabilities

Procedures are in place to provision, update, and revoke access rights in a timely manner. Access rights are reviewed periodically.

Evidence

• Periodic review of user access rights

The organisation has established, and maintains, an asset inventory. The inventory contains all information assets supporting the organisation's business functions and supporting processes, and maps information assets and dependencies on other internal and external systems and processes.

Evidence

• Inventory of assets

Developed information assets are provided with user- and technical system documentation to reduce any unnecessary dependency on subject matter experts.

Evidence

• User documentation
• Technical system documentation

Further guidance

• Documentation may describe the development, implementation, operation and/or configuration of developed assets

Dependencies are scanned for (information security) issues and vulnerabilities.

Evidence

• Configuration of a dependency scanner

Internal audits are conducted at planned intervals to provide information on whether standards and requirements that the organisation is subject to are effectively implemented and maintained.

Evidence

• Internal Audit Plana

Rules and procedures for information security and privacy are defined and communicated.

Evidence

• Information security policy

All users receive and register access to information assets under an unique ID, to ensure traceability and individual accountability for actions taken by the individual. Non-personal identification methods (e.g. shared credentials, group accounts) are tightly controlled.

Evidence

• Review of generic and shared user accounts

Developed programming code is peer reviewed before being moved into production.

Evidence

• Evidence of peer reviews

Rules and procedures are defined and implemented to protect records from loss, destruction, falsification, unauthorized access and unauthorized release.

Evidence

• Records management policy

A risk management framework has been implemented and is continuously improved based on 'lessons learned' during its implementation and monitoring. It has been approved and is being reviewed annually by management.

Evidence

• Risk management framework

Rules for the secure development of software and systems are defined and implemented.

Evidence

• Secure development framework

Rules and procedures have been defined and implemented to mitigate information security risks of working with suppliers (and other partnerships)

Evidence

• Supplier security policy

Further guidance

The following scenarios may trigger a risk assessment when working with a (new) third party:

• outsourcing of (critical) processes to third parties
• providing third parties with access to (personal or confidential) data.
• providing third parties with access to our network, systems and/or other services under our responsibility.

Third party controls should be implemented to ensure compliance with statutory, regulatory and contractual controls.

All individuals departing from employment, including key function holders, undergo a comprehensive exit process. This process includes revoking access rights.

Evidence

• Access review showing Leavers have been removed

The organisation implements and configures a threat intelligence solution that monitors publicly known vulnerabilities in software and hardware in use by the organisation, and informs the organisation of any threats detected.

Evidence

• Configuration of a threat intelligence solution
• Evidence of follow up of identified threats

The organisation understands the internal and external context it operates in.

Evidence

• Organisation context

Further guidance

Organisation context: All matters that are relevant to its purpose and that affect its ability to achieve the intended outcome(s) of its information security management system (ISMS).

The use of data is restricted according to its classification.

Evidence

• Periodic review of processing of classified data against the policy

Dynamic application security testing is periodically performed on (relevant parts of) the code base. The results are evaluated and if needed acted upon.

Evidence

• Evidence of dynamic application security testing (DAST), either with a DAST tool or as part of a planned penetration test.

Further guidance

**Dynamic application security testing (DAST): ** A process of testing an application in an operating state to find security vulnerabilities (as opposed to SAST, which is performed on source code). DAST tools analyse programs while they are executing to find security vulnerabilities such as memory corruption, insecure server configuration, cross-site scripting, user privilege issues, SQL injection, and other critical security concerns.

Potential incidents are classified and prioritised taking into consideration the likelihood and impact of the incident impacting the security and continued operations of services.

Evidence

• Review of incident in-take and assessment

Incidents are resolved adequately to mitigate the impacts related to (significant) incidents and to ensure that services remain or become operational and secure in a timely manner.

Evidence

• Review of effectiveness and timeliness of incident response activities (planned and executed response actions)

All employees, including key function holders and contractors, receive appropriate training.

Evidence

• Records of security (awareness) training

An IT strategy and related objectives and action plans, budget and resources are set, approved and managed as part of organisation's overall business strategy.

Evidence

• IT organisation strategy (optional)
• Information security objectives

Internal audits are being performed and the results are reported to relevant management. Internal audit reports shall be available as evidence of the audit programme(s) and the audit results.

Evidence

• Internal audit report(s)

Operational information that is copied to a test environment should be adequately secured, and removed in a timely manner when testing is completed. Sensitive information (including personally identifiable information) should not be copied into the development and testing environments.

Evidence

• Periodic review of information used for development and testing

Management regularly tests, assesses, and evaluates the effectiveness of technical and organisational security measures.

Evidence

• Management review of the ISMS
• Results of corrective actions

Project plans are in place to manage the development and implementation of software and systems, regardless whether this is managed inside or outside the IT organisation.

Evidence

• Roadmap for software projects
• Translation of roadmap to development milestones
• Team setup in Version Control software

Further guidance

• Elements of a project plan may include project objectives, roles & responsibilities, risk assessment, project plan, time frames and steps, key milestone, and functional and non-functional requirements.

System, applications and services are periodically subjected to vulnerability assessments and tests (e.g. red teaming, penetration testing) to validates the robustness and effectiveness of technical information security measures.

Evidence

• Security test report

Employees receive access commensurate their roles & responsibilities based on the 'need to know', 'least privileges', and 'segregation of duties' principles. Privileged access rights are tightly controlled and regularly reviewed.

Evidence

• Authorisation setup (SOLL matrix)

Application secrets are separated from source code.

Evidence

• Configuration of a service for securely storing and accessing secrets, and/or;
• Configuration of a static code analysis solution (SAST)

Any assets (and devices) provided to third parties as part of other service delivery to should be returned when supplier contracts end.

Evidence

• Evidence of return of assets provided to third parties

The attack surface of the codebase is minimized by limiting duplicate code and removing unnecessary/unused functions.

Evidence

• Evidence of duplicate code review

Rules and procedures are defined and implemented to create, maintain, and test backup copies of information, software and systems.

Evidence

• Backup policy

Disaster recovery testing is performed periodically.

Evidence

• Report of disaster recovery test

Further guidance

Disaster recovery test An exercise conducted to validate the effectiveness of the business continuity plan and identify areas for improvement. Tests may involve simulations of various scenarios to assess an organisation's readiness and enhance response capabilities, and, where applicable, the switch-over of critical business functions, supporting processes and information assets to the disaster recovery environment.

Endpoints are periodically reviewed to ensure that they remain adequately protected.

Evidence

• Evidence of endpoint compliance from mobile device management (MDM) software in use or the device itself.

Further guidance

Endpoint: Any device which stores or processed information (e.g. laptops, mobile devices) whether owned by the organization or owned privately and used on behalf of the organization [bring your own device (BYOD)].

The organisation has a clear understanding and situational awareness on evolving threats and attacker tactics in the current threat landscape, and their potential impact on the business. This information supports strategic decision-making, risk assessment, and resource allocation.

Evidence

• Analysis of external threat reports and news

The information security and privacy policies, standards and procedures have been communicated within the organisation.

Evidence

• Confirmations by employees that they have read and understand the information security policy

Logfiles of activities, exceptions, faults and other relevant events are protected (from unauthorized changes).

Evidence

• Evidence of restriction of access to Log files

Networks and network devices are secured, managed and controlled to protect information in systems and applications. This includes the logical or physical segmentation of information flows.

Evidence

• Network architecture overview

Rules and procedures are defined and implemented to ensure (personal) data collection, storage, retention and disposal is performed securely and in accordance with laws, regulations, and contracts.

Evidence

• Privacy policy

Employees receive access commensurate their roles & responsibilities based on the 'need to know', 'least privileges', and 'segregation of duties' principles. Privileged access rights are tightly controlled and regularly reviewed.

Evidence

• Evidence that privileged identities are tightly controlled

Secure baseline configurations consistent with industry-accepted system hardening standards are in place for applicable systems, applications, services, and networks. The clocks of information processing systems used by the organization are synchronized to approved time sources.

Evidence

• Secure baseline

Software development and implementation teams review and report project plans regularly to determine whether projects are on track and to identify any impact on security of any deviations from the project plan on (information security) goals.

Evidence

• Periodic software development project updates

Third party service delivery and agreements are monitored to obtain assurance over third party service delivery against the organisation's security objectives, measures and performance targets.

Evidence

• Review of service delivery

Further guidance

The third party may provide assurance as follows:

• A valid ISO 27001 certification
• A SOC2, SOC3, or ISAE3402 report covering the service scope and -period
• Insight in the operating effectiveness of their own ISMS
• Service Level Reporting

The nature and extent of assurance required is dependent on the risk profile of the third party.

Networks, systems and applications are continuously monitored for anomalous behaviour.

Evidence

• Logs of networks, systems and applications are contiously monitored

Branch Policies are applied to all repositories that are involved in deploying changes to our production environments

Evidence

• Branch policies implemented on different repositories and pipelines

Further guidance

**Branch Policy: *** A set of rules and controls applied to certain branches in a version control system (such as Git). Branch policies are designed to ensure the integrity, quality, and security of the codebase. Common branch policies enforce access control, code reviews, (automated) testing, merge methods and restrictions, and code ownership. Also known as branch protection rules or branch restrictions.

Networks and network devices are secured, managed and controlled to protect information in systems and applications. This includes the logical or physical segmentation of information flows.

Evidence

• Evidence of firewall configuration
• Evidence of port scan on production environment

A Vulnerability Disclosure and Reporting Policy (VDRP) is implemented to facilitate the responsible and secure reporting of vulnerabilities within the organization's information systems.

Evidence

• Vulnerability disclosure and reporting policy

Further Guidance

This VDRP outlines the procedures and guidelines for internal and external parties to report potential security weaknesses and vulnerabilities they may discover in the organization's IT infrastructure and information assets.