Sten Eikrem - Information Security & Risk Management

The Living Document - Lifecycle and Change Management

12 min read

The Living Document: Lifecycle and Change Management

Article 4 of 7 in the System Security Concepts series

The Living Document Challenge

Security concepts should be updated regularly. Rarely are.

System architectures evolve. Threat landscapes shift. Business requirements change. Yet security concepts often remain frozen in time—accurate at creation, outdated within months, irrelevant within a year.

The consequence: security concepts become compliance artifacts that nobody reads. Technical teams don’t consult them because they’re out of date. Auditors accept them because a document exists, even if it bears no resemblance to reality. Security governance becomes theater.

This isn’t inevitable. Organizations that integrate security concepts with system lifecycle and change management keep them current without heroic effort. The secret isn’t more process—it’s better integration with processes that already exist.

Military Time-Bound Accreditation Analogy

Military and government systems require time-bound security accreditation. A system receives authority to operate for a fixed period—typically 1-3 years. Before expiry, the system undergoes re-accreditation: threat reassessment, control validation, risk re-acceptance.

This forced review prevents documentation drift. The system can’t operate without current accreditation. Business need drives maintenance.

Commercial organizations rarely have such forcing functions. Security concept maintenance competes with feature delivery, operational firefighting, and business priorities. Maintenance loses unless integrated into existing workflows rather than added as separate obligation.

The goal: make security concept updates automatic consequences of activities already happening, not separate tasks requiring separate motivation.

Lifecycle Integration: Design, Build, Run, Change

Security concepts touch four system lifecycle phases. Integration points differ by phase.

Design Phase: Initial Creation and Project Planning Integration

When: During project inception and architecture definition, before implementation begins

Who: System architect owns creation, security team provides review and challenge, project manager incorporates security work into project plan

Input: Business requirements, threat landscape, regulatory obligations, organizational security standards, project constraints (timeline, budget, resources)

Output:

  • Initial security concept documenting system context, threats, requirements, risk assessment
  • Security work identified for project planning
  • Resource requirements identified
  • Timeline dependencies identified

The security concept isn’t just documentation—it’s a planning tool. Creating it early identifies security work that must be incorporated into project plans:

Security activities identified:

  • Threat modelling workshops (schedule participants, allocate time)
  • Security architecture reviews (book security team capacity)
  • Penetration testing (identify testing window, engage testers)
  • Compliance assessments (schedule auditors, prepare evidence)
  • Enterprise capability integration work (coordinate with IAM team, SIEM team, etc.)

Resource needs identified:

  • Security specialist time for reviews and consultation
  • External penetration testers or security consultants
  • Security tools (SAST/DAST licenses, vulnerability scanners)
  • Training for development team on security requirements
  • Enterprise capability integration effort from platform teams

Timeline impacts identified:

  • Security reviews at architecture gates (add review cycles to timeline)
  • Testing windows before go-live (penetration testing, security acceptance testing)
  • Approval processes (CISO approval, risk acceptance sign-off)
  • Integration dependencies (waiting for enterprise SSO configuration, SIEM onboarding)

Dependencies on other teams:

  • IAM team for SSO integration and configuration
  • Security operations team for SIEM integration and monitoring setup
  • Infrastructure team for network security controls
  • Compliance team for regulatory requirement validation
  • GRC team for control documentation and audit preparation

These outputs inform project planning. Security work gets appropriate resources, timing, and dependencies tracked—not discovered mid-flight as surprises.

Integration point: Part of architecture approval process and project planning. Security concept review occurs alongside functional architecture review. Security work from security concept incorporated into project plan before implementation begins. No system proceeds to implementation without approved security concept and security work properly resourced in project plan.

Implementation Phase: Control Deployment Tracking

When: Throughout system build, testing, and initial deployment

Who: System architect maintains, implementation team provides status updates

Activity: Track control implementation status. Security concept moves from “planned” controls to “implemented” controls as system builds out.

Integration point: Sprint reviews or milestone gates include security concept status updates. “These controls were implemented this sprint. These remain in progress.”

Risk: Security concept and implementation diverge. Concept documents controls that weren’t implemented. Implementation includes controls not documented.

Mitigation: Implementation team references security concept during build. Acceptance criteria include “control X implemented per security concept requirement.”

Operations Phase: Ongoing Maintenance

When: After go-live, throughout operational lifetime

Who: System architect maintains, security team provides threat intelligence, change managers trigger reviews

Activity: Periodic reviews even without changes. Threat landscape updates. Regulatory requirement changes. Organizational policy updates.

Integration point: Annual or bi-annual scheduled review as minimum. Security concept included in system health reviews alongside availability, performance, cost.

This is the hardest integration to maintain. No immediate consequence of skipping the review. Business pressure always has higher priority.

Success pattern: CISO or security governance team tracks security concept currency. Systems with outdated concepts get escalated. Business owners must explain why review hasn’t occurred or commit to completion date.

Change Phase: Triggered Updates

When: System undergoes significant change

Who: Change initiator triggers review, system architect updates concept, security team reviews changes

Activity: Assess whether change affects security concept. If yes, update relevant sections before change implementation.

Integration point: Change management process includes security concept impact assessment. Change request template asks “Does this change affect the security concept?” If yes, concept update is prerequisite for change approval.

This integration works because change management already exists and is enforced. Adding security concept check to existing process creates minimal friction.

Change Management Integration: What Triggers Updates

Not every change affects the security concept. Distinguish signal from noise.

Changes That Require Security Concept Updates

Architecture changes:

  • New integration points (data flow to/from external systems)
  • Technology platform migration (on-premise to cloud, cloud provider change)
  • Network architecture changes (new zones, firewall rule changes, VPN access)
  • Authentication method changes (local auth to SSO, MFA implementation)

Data changes:

  • Data classification level increase (internal to confidential, confidential to restricted)
  • New data types (adding PII, payment card data, health records to previously non-sensitive system)
  • Data retention period extension (affects backup and archive controls)
  • Geographic data residency changes (affects compliance obligations)

User population changes:

  • External user access added (partners, customers, contractors)
  • Admin user population expansion (privilege management requirements)
  • Cross-border user access (affects data transfer controls)

Regulatory scope changes:

  • System now in scope for regulation previously not applicable (GDPR, NIS2, PCI DSS)
  • Compliance obligation changes due to business expansion
  • Contractual security requirements from new customer

Threat landscape updates:

  • Major vulnerability affecting system platform (Log4j, Heartbleed-scale events)
  • Industry-wide attacks targeting similar systems (supply chain attacks, ransomware campaigns)
  • Specific threat intelligence indicating organization or industry targeting

Changes That Don’t Require Updates

Routine operational changes:

  • Software patches and minor version updates (unless addressing architectural vulnerability)
  • User account creation/deletion within existing user populations
  • Configuration changes within documented parameters
  • Scaling within existing architecture (add server instances, increase capacity)

Minor feature additions:

  • New functionality using existing security architecture
  • UI/UX improvements not affecting authentication/authorization
  • Reporting enhancements not changing data access patterns

Integrating with Change Advisory Board (CAB)

CAB process provides natural integration point. Change request template includes security concept impact assessment:

## Security Concept Impact Assessment
 
Does this change affect:
- System architecture or integrations? [Yes/No]
- Data classification or types handled? [Yes/No]
- User populations or access methods? [Yes/No]
- Regulatory scope or compliance obligations? [Yes/No]
 
If any Yes: Security concept update required before change approval
Security concept update completed: [Yes/No] [Version reference]
Security team review required: [Yes/No]

CAB reviews assessment. Changes with security concept impact don’t proceed until concept updated and reviewed.

This creates accountability without adding process. CAB already exists. Change requests already require approval. Adding security concept check takes minutes, prevents hours of rework.

Version Control and Approval Workflow

Treat security concepts like code: version control, change tracking, approval workflow.

Version control approach:

  • Major version: Significant architectural change, threat model update, risk reassessment
  • Minor version: Control implementation status update, organizational policy reference update
  • Patch: Formatting, spelling, contact information updates

Approval workflow:

  • Minor/patch changes: System architect approval sufficient
  • Major changes: Security team review + business owner approval + risk acceptance sign-off if risk profile changes

Document control section tracks version history:

| Version | Date | Changes | Approval |
|---------|------|---------|----------|
| 1.0 | 2024-01-15 | Initial creation | J. Smith (Architect), M. Johnson (Security), L. Brown (Business Owner) |
| 1.1 | 2024-03-20 | Control implementation status updated | J. Smith (Architect) |
| 2.0 | 2024-07-10 | Cloud migration - architecture and control updates | J. Smith (Architect), M. Johnson (Security), L. Brown (Business Owner) |

Threat Landscape Updates: When to Review

Threat landscapes evolve faster than systems change. Security concepts must adapt without constant churn.

Scheduled Threat Review

Annual minimum: Review threat model against current threat landscape even without system changes. Ask:

  • Are threat actors still same? (Geopolitical changes, industry targeting shifts)
  • Are attack vectors still relevant? (New vulnerability classes, retired technologies)
  • Are business impacts still accurate? (Regulatory fines increased, customer expectations changed)
  • Are controls still effective? (Attack techniques evolved, control bypass methods emerged)

Document review date and outcome: “Threat model reviewed 2024-11-15. No material changes to threat landscape affecting this system. Next review due 2025-11-15.”

If material changes identified, trigger threat model update even without system change.

Event-Triggered Review

Certain events warrant immediate threat review:

Major vulnerability announcements: Log4Shell, Heartbleed, major cloud provider vulnerabilities affecting system platform or dependencies.

Industry-specific attacks: Ransomware campaign targeting your industry, supply chain compromise affecting similar organizations, widespread exploitation of common technology.

Organizational incidents: Security incident affecting similar systems, penetration test findings revealing new attack patterns, threat intelligence indicating organization-specific targeting.

Regulatory change: New security requirements, updated threat definitions, incident reporting thresholds.

Threat Intelligence Integration

Organizations with threat intelligence programs feed updates to security concept owners.

Lightweight integration: Quarterly threat intelligence summary to system architects highlighting:

  • Threats relevant to specific system categories (web applications, APIs, OT systems)
  • Vulnerability trends affecting common platforms
  • Attack technique evolution requiring control updates
  • Industry threat landscape changes

System architects assess applicability. If relevant, security concept threat model updated.

Heavy integration: Threat intelligence platform automatically flags systems potentially affected by new threats based on technology inventory and data classification.

Both approaches work. The key: threat intelligence reaches system architects, not just security operations.

Practical Triggers and Workflows

Theory is useless without practical implementation. Here’s how organizations make this work:

Automated Triggers

Change management system integration:

  • Change requests tagged “security-relevant” trigger automatic notification to security concept owner
  • Change cannot complete until concept update status confirmed
  • Dashboard shows systems with pending security concept updates blocking changes

Asset management system integration:

  • Technology inventory changes trigger review (platform upgrade, new integration, decommissioned dependency)
  • Data classification changes trigger automatic review request

Calendar-based triggers:

  • Annual review calendar with automated reminders 30/60/90 days before due date
  • Overdue security concepts escalated to CISO/business owner

Manual Workflows

Security concept review board:

  • Monthly or quarterly meeting reviewing security concepts pending update
  • System architects present changes, security team provides challenge, business owners accept risk updates
  • Documented decisions for audit trail

Incident response integration:

  • Post-incident review includes security concept impact assessment
  • If incident revealed gap between documented and actual controls, security concept updated as part of remediation

Audit integration:

  • Auditors review security concept currency as part of control testing
  • Out-of-date concepts become audit findings
  • Remediation requires concept update and process improvement

Effort Estimation

How much effort does security concept maintenance actually require?

Initial creation: 3-5 days for comprehensive security concept (complex system, thorough threat model, detailed requirements)

Minor updates: 2-4 hours (control status updates, organizational policy reference updates)

Major updates: 1-2 days (architectural change, threat model refresh, significant control additions)

Annual review: 4-8 hours (review all sections, validate currency, update where needed)

Compared to initial implementation cost of most systems, this is negligible. The challenge isn’t effort—it’s attention and priority.

Successful organizations make maintenance automatic consequence of existing processes rather than separate obligation requiring separate prioritization.

Indicators of Healthy Maintenance

How do you know if security concept maintenance is working?

Currency Metrics

  • Percentage of systems with security concepts reviewed within last 12 months: Target >80%
  • Average age of security concept: Target <12 months
  • Number of systems with overdue reviews: Target <10% of portfolio

Quality Metrics

  • Percentage of security concepts updated during major system changes: Target 100%
  • Percentage of audit findings related to outdated security concepts: Target <5% of security findings
  • Percentage of incidents revealing security concept/reality gaps: Target <10% of incidents

Integration Metrics

  • Percentage of change requests with security concept impact assessment completed: Target 100%
  • Average time from change request to security concept update: Target <5 days
  • Number of changes blocked due to security concept update requirement: Trend (not target—measure, understand why)

Stakeholder Satisfaction

  • Architects: Is security concept helpful during design and change? (Survey)
  • Security team: Are security concepts accurate enough to rely on for review? (Survey)
  • Auditors: Do security concepts provide adequate evidence? (Audit feedback)

Conclusion

Security concepts are living documents. The challenge isn’t creating them—it’s keeping them current without heroic effort.

Integration is key. Link security concept updates to existing processes: change management, lifecycle gates, audit cycles. Make updates automatic consequences of activities already happening.

Define clear triggers: what changes require updates, what don’t. Build workflows that make security concept status visible. Track currency metrics. Escalate out-of-date concepts.

The alternative is security concepts that document how systems used to work, not how they work now. Compliance theater. Auditors accept them because documents exist. Technical teams ignore them because they’re wrong. Security governance becomes checkbox exercise.

Organizations that solve the living document challenge gain operational benefit beyond compliance. Current security concepts enable faster change approval. They support portfolio-level security visibility. They inform similar system designs. They demonstrate security maturity to customers and regulators.

Article 5 addresses enterprise security capability integration—the most commonly missed component of security concepts. How to document IAM, SIEM, DLP, and monitoring integration. How to avoid reinventing controls that already exist. How security concepts enable portfolio architecture visibility.

Next in series: Article 5 - Enterprise Security Capabilities: The Integration Challenge

Article 4 of 7 | Ready for publication Target audience: Security Architects, System Architects, Change Managers, Project Managers Word count: ~2,450

Graph View

Backlinks