Cybersecurity self-assessments are an important part of securing industrial and operational technology (OT) environments. They provide a structured way to verify that a system meets the security requirements established through risk assessment, standards, and the needs of the end user.
A self-assessment is one part of the broader cybersecurity process. Before assessing whether a system meets its security requirements, you need to understand what you are assessing, what could go wrong, and how much risk is acceptable. This typically involves:
The actual self-assessment can then be performed using a compliance sheet or assessment template. The questions should be aligned with the applicable security level and the requirements identified during the risk assessment. The objective is to determine whether the system fully meets the requirements, partially meets them, or has gaps that need to be addressed.
The primary purpose is to document that the delivered system meets the cybersecurity requirements established through the risk assessment. This provides a documented basis for answering a critical question:
Is the system sufficiently secure for its intended purpose and risk level?
A completed assessment gives the end user greater visibility into the security of the system. It also provides cybersecurity engineers and project teams with a structured way to identify gaps before they become operational problems.
Failing an assessment does not necessarily mean that it is unusable. It means that one or more requirements have not been adequately addressed and that further action is needed. The consequences of leaving those gaps unresolved can, however, be significant.
A system with insufficient security may contain vulnerabilities that could be exploited by a hacker. This is also relevant in OT environments, where cybersecurity incidents can potentially affect not only data and IT systems, but production, availability, safety, and physical processes.
Hackers are increasingly familiar with industrial environments and the protocols and technologies used in OT. This means that relying on the assumption that industrial systems are too specialised to be targeted is no longer a sufficient security strategy.
Industrial environments often contain a large number of devices and software accumulated over many years. Some may be well documented, while others may have been installed as part of a project, upgrade, or maintenance activity without being properly added to an asset inventory.
A comprehensive asset inventory needs to provide visibility into the products, devices, software, versions, connections, and other relevant components that make up the system. Without this visibility, you may not know when new products are introduced into the environment. You may also fail to identify vulnerabilities or outdated components that require attention.
A device may still perform its intended function perfectly while running outdated software, operating systems, or firmware. Replacing such equipment may also be difficult because of production requirements, compatibility issues, or the cost and complexity of an upgrade.
If you know that a device has a specific vulnerability, you can assess the associated risk and introduce appropriate countermeasures. These could include network segmentation, access restrictions, monitoring, compensating controls, or planned replacement. If the device is not known or documented, however, the vulnerability may remain completely invisible.
A practical self-assessment can be organised into four main steps.
Start by clearly defining the System Under Consideration (SUC): Determine exactly which systems, devices, software, networks, and components are included in the assessment. This scope needs to be precise. If assets are excluded from the SUC without a clear reason, important security gaps may remain outside the assessment. Creating or validating the asset inventory at this stage is therefore essential.
Once the scope has been defined, select or develop the appropriate assessment template. The template should reflect the cybersecurity requirements applicable to the system and its required security level.
Questions should be structured so that the assessor can determine whether each requirement is:
It is also important to document evidence for the answers. A "yes" should be supported by relevant technical documentation, configuration information, procedures, or other evidence where appropriate.
Cybersecurity assessments are rarely completed effectively by one person working in isolation. Bring the relevant parties together in a workshop. This can include cybersecurity engineers, system engineers, asset owners, integrators, and representatives from the vendors supplying the different components.
The vendor's technical personnel can provide valuable information about how their products are implemented, configured, maintained, and secured, which is particularly important when the system consists of multiple products and technologies. A workshop also creates an opportunity to identify inconsistencies between the documented architecture and the actual implementation.
The final step is to complete the compliance assessment and document the results. For each requirement, determine whether it is fully met, partially met, or not met. Any deviations should be documented together with their associated risks and recommended actions.
The resulting report can then be submitted to the end user as evidence of the system's cybersecurity status. If a product or component cannot meet a required cybersecurity requirement, the assessment should not simply end with a "non-compliant" finding.
It’s at that point we need to consider what has to change to reduce the risk to an acceptable level. This could mean modifying the product, changing its configuration, introducing additional security controls, implementing compensating measures, or replacing the component altogether.
There is significant value in performing a self-assessment internally, particularly because the people closest to the system often have the best understanding of its architecture and operational requirements.
However, an independent third party can provide a valuable additional perspective. An external cybersecurity specialist brings an unbiased view and can identify issues that internal teams may overlook. This can be particularly valuable during risk assessments, where assumptions about how systems work can influence the outcome.
External specialists also bring experience from working with different systems, technologies, vendors, and implementations. Leveraging industry best practices and experience can help identify practical solutions and avoid reinventing the wheel. The combination of internal system knowledge and external cybersecurity experience can therefore result in a much stronger assessment.
A cybersecurity self-assessment should not be treated as a box-ticking exercise. The real value comes from understanding why a requirement exists, what risk it addresses, and whether the implemented controls actually provide the required level of protection.
For OT environments, this means combining cybersecurity requirements with a clear understanding of the system, its assets, its operational dependencies, and its potential consequences.
Ultimately, the goal is not simply to pass an assessment. It is to build a system where cybersecurity requirements are understood, measurable, and addressed throughout the engineering lifecycle.