Open/Closed Principle

Expanded Definition

The Open/Closed Principle is a design rule for software structure: existing modules should keep their established behaviour stable while new behaviour is introduced through extension points such as interfaces, composition, strategy objects, or plug-ins. It is usually applied to reduce regression risk, make code easier to evolve, and keep core logic from becoming a rewrite target every time requirements change.

The principle does not mean code should never change. It means changes should be concentrated at intentional boundaries rather than by editing a working component every time a new case appears. That boundary is often misunderstood: a system can be “open” in one place and still be tightly controlled elsewhere, which is normal and often desirable. In practice, good use of the principle is judged by how cleanly variation is isolated, not by whether a class is literally never edited again. For readers working with modern software delivery, the most useful boundary question is whether a new requirement can be added without destabilising the behaviour already relied on by other parts of the system.

For a concise external reference on the adjacent identity-security design concerns that often arise when software boundaries are extended, see the OWASP Non-Human Identity Top 10.

Examples and Use Cases

• A payment service adds a new fraud rule by introducing a rule interface rather than editing a long conditional chain in the checkout flow.
• A notification system supports email, SMS, and push by registering channel handlers, so each channel can evolve independently.
• A policy engine keeps its core evaluation path stable while new policy types are added through plug-in modules.
• An AI-generated codebase uses a small abstraction layer around external APIs so prompt-driven feature additions do not repeatedly alter the same core function.
• A platform team exposes extension points for tenant-specific logic, which helps preserve the shared baseline while allowing controlled variation.

The main trade-off is that extension mechanisms add structure up front. If the variation is still speculative, over-engineering abstractions can make the code harder to read than a direct edit would have been.

Security Implications

When the Open/Closed Principle is ignored, security-sensitive logic often becomes a dense editing hotspot. That raises regression risk because each new feature, exception, or workaround can quietly alter authentication checks, authorisation paths, validation rules, logging behaviour, or error handling. A component that is repeatedly modified in place also becomes harder to review for unintended privilege changes, bypass conditions, and inconsistent enforcement.

Security impact usually shows up as fragile control boundaries rather than dramatic failure. A direct modification to a shared module can create one-off exceptions that bypass the intended path, or it can duplicate logic across multiple call sites until controls drift apart. That drift is especially dangerous when the code governs input validation, trust decisions, or privilege-sensitive workflow steps, because the system may appear to work while silently enforcing different rules in different places.

A practical sign of trouble is when teams keep patching the same function to accommodate new cases. That is often a signal that the design no longer isolates variation well enough for safe change.

Domain and Governance Relevance

In software engineering governance, the principle matters because it is a maintainability and change-control discipline, not just a coding style preference. It supports safer evolution of shared components, clearer ownership of extension points, and more predictable review scope when business logic changes. That predictability is especially valuable in systems where change velocity is high and regression tolerance is low.

Where the code also mediates access, credentials, or automation, the design boundary becomes more consequential. Extension through well-defined interfaces helps keep sensitive behaviour visible and reviewable, rather than scattering special cases across the codebase. For NHIMG, the relevant point is not that every design pattern becomes an identity issue, but that unstable core logic can undermine control consistency when software handles privileged or machine-driven actions. The principle therefore supports governance by making critical behaviour easier to reason about, test, and audit over time.

In practice, teams should treat the principle as a way to preserve control integrity during change, not as a mandate to abstract everything.

Related resources from NHI Mgmt Group

• Should organisations choose open-source or closed models for sensitive use cases?
• How do organisations decide when open source helps AI security more than closed systems?
• What is the difference between open and closed AI training data from a security perspective?
• Should organisations fail open or fail closed when prompt redaction breaks?