Article 5 of 7 in the System Security Concepts series
The integration gap
Most security concepts document what controls a system should have. Few document how the system leverages enterprise security capabilities that already exist.
This is the most common gap in security concept maturity. Organisations invest millions in IAM platforms, SIEM systems, vulnerability management, DLP, and security testing tools, then document systems as if these capabilities don’t exist. Each security concept reinvents authentication, logging, monitoring, and vulnerability management as if starting from zero.
The consequences:
Control duplication: Systems build local authentication when enterprise SSO exists. Applications implement custom logging when SIEM integration is available. Teams create system-specific vulnerability tracking when enterprise processes exist.
Integration failures: Dependencies on enterprise capabilities remain undocumented until they fail. SSO outage affects 50 systems, but nobody knew which ones. SIEM upgrade breaks application logging, surprising application teams.
Invisible architecture: Security concepts describe system-level controls. Stack them together and you see… disconnected islands. The actual enterprise security architecture, the capabilities systems share, remains invisible. The CISO can’t answer ‘how mature is our IAM capability?’ because no view shows which systems use it and how.
Lost optimisation opportunities: Similar systems solve identical problems differently because previous solutions aren’t documented in reusable form. Authentication patterns, monitoring configurations, access control models, reinvented repeatedly.
The solution: document enterprise security capability integration explicitly in every security concept.
What are enterprise security capabilities?
Enterprise security capabilities are shared security services, platforms, and processes that multiple systems use.
Common enterprise capabilities:
Identity and access management (IAM)
- Single sign-on (SSO) platforms (Azure AD, Okta, Ping Identity)
- Privileged access management (CyberArk, BeyondTrust)
- Access governance and access reviews
- Multi-factor authentication enforcement
- Identity lifecycle management (provisioning/de-provisioning)
Security monitoring and detection
- Security information and event management (SIEM) (Splunk, QRadar, Sentinel)
- Security orchestration, automation and response (SOAR)
- User and entity behaviour analytics (UEBA)
- Network detection and response (NDR)
- Endpoint detection and response (EDR)
Vulnerability and threat management
- Vulnerability scanning (Qualys, Tenable, Rapid7)
- Penetration testing programs
- Security testing in development (SAST/DAST/SCA)
- Threat intelligence platforms
- Security posture management
Data protection
- Data loss prevention (DLP) (Forcepoint, McAfee, Symantec)
- Email security gateways
- Cloud access security brokers (CASB)
- Encryption key management
- Data classification tools
Incident response
- Incident response procedures and playbooks
- Security operations centre (SOC)
- Forensic investigation capabilities
- Crisis management processes
Governance and compliance
- GRC platforms (ServiceNow, RSA Archer)
- Policy management and distribution
- Compliance monitoring and reporting
- Security awareness training
Not all organisations have all capabilities. Mature organisations have most. Even organisations with limited capabilities have some shared services: enterprise antivirus, network firewalls, backup systems.
The question isn’t ‘do we have enterprise capabilities?’ but ‘which capabilities do we have, and how do systems integrate with them?‘
Documenting capability integration
Document capability integration in three parts: what exists, how this system uses it, and what gaps remain.
What enterprise capabilities exist
Security concepts reference organisational capability inventory:
The organisational capability inventory covers identity and access management, security monitoring, vulnerability management, data protection, and incident response — documenting the specific technologies, services, and teams available. This inventory should be centrally maintained and referenced by all security concepts rather than duplicated in each one.
How this system integrates
For each relevant capability, document integration:
For each relevant capability, document the integration using a consistent structure. This format answers five questions:
- Which enterprise capability applies?
- How does the system integrate technically?
- What security benefits does the system inherit?
- What system-specific controls supplement enterprise capability?
- What breaks if the enterprise capability fails?
Gap analysis: where enterprise capabilities don’t cover requirements
Enterprise capabilities may not satisfy all requirements. Document gaps by specifying the requirement, what the enterprise capability provides, where the gap lies, what system-specific control addresses it, and the rationale for why a system-specific approach is necessary.
Gap documentation serves three purposes. First, it prevents ‘why doesn’t this system use enterprise capability?’ questions by explaining why system-specific controls are necessary. Second, it identifies opportunities for enterprise capability enhancement: if five systems have the same gap, maybe enhance the enterprise capability. Third, it provides transparency for risk assessment, as gaps mean potential inconsistency in control implementation.
The architecture view: stacking security concepts
Individual security concepts document how one system integrates with enterprise capabilities. Stack all security concepts together and you see your actual enterprise security architecture.
Portfolio-level questions security concepts answer
When all security concepts follow a consistent structure, they become queryable. Search all concepts for ‘Azure AD’ integration sections and you discover 47 systems integrated with SSO, while 8 use local authentication: 6 legacy systems pending migration, 2 OT systems with technical constraints documented in their concepts. This visibility enables migration planning and exception management.
Dependency analysis becomes straightforward. Search for ‘Splunk’ dependencies across all concepts and identify 52 systems forwarding logs. Of these, 15 are marked ‘critical dependency’ with no fallback, while 37 have ‘degraded functionality’ status with local logging fallback. Security concepts make blast radius analysis possible without manual investigation.
Control consistency patterns emerge from aggregation. Compare authentication sections across web applications and find 34 use Azure AD SSO, 5 use Okta (M&A remnants), and 2 use local authentication. These inconsistencies, documented in security concepts, flag systems for remediation or exception approval.
Compliance scope verification becomes efficient. Filter security concepts by ‘PCI DSS’ compliance tags, then check DLP and encryption integration sections. All 8 in-scope systems use Microsoft Purview DLP and required encryption, with control consistency verified through documentation rather than audit scrambling.
Portfolio maturity assessment
Security concepts enable capability maturity assessment:
IAM Capability Maturity Analysis (60 systems analyzed):
- SSO Integration: 78% (47/60 systems)
- MFA Enforced: 85% (51/60 systems) - higher than SSO due to local MFA in some legacy systems
- Privileged Access via CyberArk: 45% (27/60 systems) - gap identified, roadmap needed
- Access Reviews: 92% (55/60 systems) - strong coverage
This data-driven view enables informed investment decisions. The IAM platform is well-adopted for authentication and MFA. Privileged access management adoption is weak: investigate why and create adoption roadmap. Access review process is mature and widely implemented.
Identifying capability gaps and duplicates
Security concepts reveal where enterprise capabilities should exist but don’t:
Gap pattern identified: 12 web applications implement custom rate-limiting/DDoS protection
- Observation: No enterprise capability for application-layer DDoS protection
- Recommendation: Evaluate enterprise Web Application Firewall (WAF) to provide consistent protection and reduce duplication
Gap pattern identified: 8 systems implement custom secrets management
- Observation: No enterprise secrets management capability (vault, key management)
- Recommendation: Implement HashiCorp Vault or Azure Key Vault as enterprise capability
Security concepts also reveal redundant capability investments:
Redundancy identified: 3 different SAST tools in use across application portfolio
- SonarQube: 25 applications
- Checkmarx: 15 applications
- Veracode: 8 applications
- Observation: Overlap without clear selection criteria
- Recommendation: Standardise on one platform, migrate applications, save licensing costs
Practical integration examples
Abstract principles need concrete examples. Different system types integrate with enterprise capabilities in fundamentally different ways. SaaS applications like Salesforce leverage vendor-provided integration points: SAML for SSO, SCIM for provisioning, API forwarding for monitoring. Internal web applications built on modern stacks integrate deeply with enterprise services: Azure AD for authentication, Application Insights for performance, Splunk for security events. Legacy systems present integration constraints requiring compensating controls and explicit risk acceptance. These patterns repeat across similar system types.
Integration patterns differ by system type. A SaaS application leverages supplier-provided integration points for SSO, provisioning, monitoring, and security posture management. An internal web application on a modern stack integrates deeply with enterprise IAM, SIEM, and vulnerability management services. A legacy system presents integration constraints requiring compensating controls and explicit risk acceptance — with documented migration plans where applicable.
The key difference isn’t the technology — it’s how honestly the security concept documents what integrates well, what doesn’t, and what compensating controls bridge the gap.
Benefits of explicit integration documentation
Documenting enterprise capability integration provides multiple benefits:
For system architects:
- Clear guidance on what to use vs. build
- Reduce rework from missed capability dependencies
- Faster design decisions (reference previous integration patterns)
For security teams:
- Portfolio visibility without investigating every system individually
- Consistent control implementation across systems
- Identify adoption gaps and prioritise remediation
For business owners:
- Understand dependencies on shared services
- Plan for enterprise capability changes (migration impact analysis)
- Justify system-specific control costs when enterprise capabilities don’t fit
For auditors:
- Evidence that controls are actually implemented, not just documented
- Consistent control application across system portfolio
- Clear accountability for enterprise vs. system-specific controls
For CISO/leadership:
- Data-driven enterprise capability investment decisions
- Security architecture visibility (actual, not theoretical)
- Maturity assessment based on real adoption data
Conclusion
Enterprise security capabilities represent significant organisational investment. Most security concepts ignore them, documenting systems as isolated islands rather than integrated architecture.
The integration gap creates control duplication, invisible dependencies, and lost optimisation opportunities. Organisations reinvent authentication, monitoring, and vulnerability management repeatedly because previous solutions aren’t documented in reusable form.
The solution: document enterprise capability integration explicitly. Show what capabilities exist, how systems use them, where gaps remain, and why system-specific controls are necessary.
Stack all security concepts together and you gain portfolio-level visibility. How many systems use IAM? Which depend on SIEM? Where are controls inconsistent? This enables data-driven capability investment and maturity assessment.
Article 6 examines access control and data protection in detail, two security domains that appear in every security concept yet are often poorly documented. How to specify authentication requirements, define authorisation models, classify data, and document encryption implementation.
Next in series: Article 6 - Access Control and Data Protection: Getting the Details Right
Article 5 of 7 | Ready for publication Target audience: Security Architects, Enterprise Architects, CISO Word count: ~2,450