Our Security and Compliance Foundation

Security and compliance only become meaningful when they are built into the system itself. That sounds obvious, but in practice it is where many companies lose the plot. Frameworks get listed, controls get documented, and a reassuring number of acronyms appear on websites and procurement forms, while the underlying system remains far less coherent than the paperwork suggests. That is not how we approach it at Kolsetu. We work with regulated enterprises, and we are expected to meet that standard properly. That means choosing frameworks that serve a clear purpose, reinforce each other, and reflect how our systems are actually built, operated, and maintained. The standards we align with are not there for decoration. They form the structure behind how we manage security, cloud risk, operational controls, and data protection in practice. Each of them covers a different aspect. Together, they give us a security and compliance foundation that is structured, practical, and adaptable.

Why These Frameworks

Each of the frameworks we align with serves a specific role. They are not interchangeable, and they are not there for coverage on a slide. Together, they address different aspects of the same problem: how to build and operate systems that remain secure over time.

ISO 27001 - The Foundation of Security Management

ISO 27001 provides the structure. It defines how security is managed as a system: ownership, risk management, documentation, and continuous improvement. It ensures that controls are not applied inconsistently or dependent on individual decisions. The standard is built around a risk-based approach and supported by Annex A, which defines a comprehensive set of security controls covering areas such as access management, cryptography, supplier relationships, and incident handling. In practice, this is what prevents security from drifting over time. It creates accountability, auditability, and a baseline that can be relied on beyond individual teams or projects.

NIST Cybersecurity Framework - Managing Risk in Context

The NIST Cybersecurity Framework provides a model for understanding and managing risk. Its structure — Identify, Protect, Detect, Respond, Recover — is simple, but effective. It allows organisations to assess where they stand, prioritise improvements, and make decisions based on risk rather than assumptions. Underneath that structure sits a detailed catalogue of categories and subcategories that map security outcomes to concrete capabilities. This makes it particularly useful for aligning technical controls with business risk. It is less about ticking boxes and more about understanding exposure, and making informed trade-offs.

CIS Controls - What Actually Gets Implemented

The CIS Controls are where things become concrete. They define a prioritised set of 18 controls, grouped by implementation levels depending on organisational maturity and risk exposure. The focus is on the controls that reduce the most common and most damaging risks: asset visibility, access control, vulnerability management, and monitoring. They are deliberately practical. If ISO defines how security is managed, CIS defines what actually gets done. It is often seen as a pragmatic counterpart to more audit-heavy frameworks — not a replacement, but a way to ensure that essential controls are actually in place and functioning.

CSA STAR - Cloud Security without Illusions

CSA STAR addresses a reality that many frameworks only touch indirectly: modern systems run in the cloud. It builds on the Cloud Controls Matrix (CCM), which maps security controls specifically to cloud environments and aligns them with other major frameworks. This allows organisations to demonstrate cloud-specific security posture in a structured and comparable way. It focuses on shared responsibility models, multi-tenant environments, and distributed infrastructure, the areas where assumptions tend to fail if they are not made explicit. For cloud-native systems, this is not an extension. It is essential.

GDPR - Data Protection as a Baseline

GDPR is not a framework we chose. It is the baseline we operate under as a European company. It defines how personal data is handled, what rights individuals have, and how organisations are held accountable. This includes principles such as data minimisation, purpose limitation, and accountability, as well as strict requirements around breach notification and data subject rights. More importantly, it forces data protection into system design, through concepts such as privacy by design and by default, rather than allowing it to remain a policy exercise. For an EU-based company compliance to this regulation, this is not optional. It is foundational.

Data Privacy Beyond GDPR - Designed for Adaptation

Operating across regions means encountering additional privacy frameworks. Personal data protection regulation variants, sector-specific regulations, and jurisdiction-specific requirements introduce variations - sometimes meaningful, sometimes largely terminological. Because our systems are built to GDPR-level rigor, we do not need to redesign them for each of these frameworks. In practice, alignment means:

• deploying within the required jurisdiction,
• applying region-specific configurations, and
• addressing specific control differences where they exist

The core system remains unchanged. This avoids fragmentation and ensures that compliance does not introduce inconsistencies into how the system behaves.

How These Frameworks Work Together

These frameworks are not layered randomly:

• ISO ensures the system is structured and governed
• NIST provides a way to reason about risk
• CIS ensures the critical controls are actually implemented
• CSA STAR ensures those controls work in cloud environments
• GDPR ensures data protection is built in

Together, they form a system that is both defined and operational.

Why We Do Not Add Everything

We can align with additional frameworks when required. However, adding them pre-emptively does not make the system more secure. It increases documentation, expands mapping, and adds complexity to communication. The underlying controls do not improve simply because they are described in more ways. This also includes additional ISO standards such as 27017 and 42001, which we have fully implemented to extend our foundation into cloud security and AI governance. Formal certification in these areas is not always proportionate to the value it adds, but the underlying controls are implemented regardless. At some point, additional frameworks stop adding clarity and start adding noise. Our focus is to keep the system itself clear, consistent, and reliable.

Conclusion

Compliance is necessary. But it is not the objective. The objective is a system that behaves correctly, consistently, and predictably - even under pressure. Frameworks support that, they do not replace it.