Article 6 of 7 in the System Security Concepts series
Why details matter
Access control and data protection appear in every security concept. Yet they’re often documented poorly, with generic statements that provide no implementation guidance, miss critical details, and frustrate both architects and auditors.
Generic: ‘System implements role-based access control’ Missing: Which roles exist? What can each role do? How are roles assigned? Who reviews access?
Generic: ‘Data is encrypted in transit and at rest’ Missing: Which encryption algorithms? Where are keys stored? Who can decrypt? What data isn’t encrypted and why?
The problem isn’t that these details don’t exist, as architects implementing the system know them. The problem is they’re not documented in the security concept, creating three failures:
Design review failure: Security teams can’t meaningfully review access control design without knowing the authorisation model. ‘We use RBAC’ tells them nothing.
Audit failure: Auditors need evidence that access controls work as designed. Generic statements provide no testable criteria.
Change management failure: When architects change, knowledge walks out the door. The next architect must reverse-engineer access control logic from code.
This article addresses how to document access control and data protection with enough detail to enable review, audit, and maintenance without overwhelming the reader with implementation specifics.
Authentication: who are you?
Authentication proves user identity. Most systems inherit authentication from enterprise IAM capability (covered in Article 5). What belongs in the security concept is authentication requirements, not authentication implementation.
Authentication strength requirements vary by user population. Each population — standard users, administrative users, API clients, external partners — has different risk profiles that demand different authentication strength. The security concept should specify the authentication method, required factors, session management parameters, and re-authentication triggers for each population.
The key is specifying requirements without implementation details. Architects know what authentication strength to implement. Security reviewers can assess adequacy. Auditors can test implementation against requirements.
Document how the system responds to authentication failures:
Account lockout: 5 failed attempts within 15 minutes → account locked for 30 minutes
- Rationale: Balance brute-force protection with user convenience
- Unlock: Automatic after 30 minutes, or manual by service desk
Suspicious activity: Impossible travel, unusual location, compromised credential detected → require additional authentication challenge
- Implementation: Azure AD Identity Protection
- User Impact: Additional verification required before access granted
Failed MFA: User fails MFA challenge → authentication denied, incident logged
- No fallback to single-factor authentication
- Service desk can provide temporary access code (valid 15 minutes, single use)
If the system accepts authentication from external identity providers, document the trust model: which providers are trusted, what attributes they must provide, certificate requirements, metadata management, revocation timelines, and how external users are mapped to internal authorisation roles after authentication.
Authorisation: what can you do?
Authentication proves who you are. Authorisation determines what you can do. This is where security concepts frequently lack detail.
Don’t just state ‘system uses RBAC.’ Document the authorisation model with role definitions that map each role to its business function, typical users, and permissions summary. A permission matrix showing exactly which functions each role can perform makes authorisation testable rather than theoretical.
Beyond roles and permissions, document the role assignment process (who requests, who approves, how it’s implemented), segregation of duties constraints (which role combinations are prohibited), and access review cadence.
This level of detail enables design review (security team assesses whether the model prevents common risks), implementation guidance (developers know exactly what each role can do), and audit testing (auditors can verify role assignment and segregation of duties).
Some systems require finer-grained access control than role-based. Data-level access controls restrict visibility based on customer assignment, geography (particularly relevant for GDPR), or time windows (financial close periods). These constraints should be documented alongside the RBAC model, showing how role-based and data-level controls interact.
Privileged access management deserves specific attention: which operations are privileged, how just-in-time elevation works, approval requirements, session duration limits, and emergency break-glass procedures. Every privileged operation should be logged with business justification.
Data classification and handling
Data classification drives protection requirements. Most organisations have classification schemes. Few security concepts document how they’re applied to specific systems.
For each classification level, the security concept should inventory what specific data elements the system handles (not generic terms — name the actual fields), their approximate volume distribution, and the storage, transmission, retention, and disposal requirements appropriate to that classification.
Data handling requirements then flow from classification: who can access, how data can be shared internally and externally, export controls and audit logging, display masking rules for sensitive fields, and secure disposal methods. Each classification level gets specific handling requirements rather than a single generic policy applied uniformly.
Encryption: protecting data
‘Data encrypted at rest and in transit’ is insufficient. Specify what, how, and why.
Encryption in transit should be specified per communication path: external (internet-facing), internal (service-to-service), and any non-encrypted channels with rationale for the exception. Specify protocol versions, minimum cipher suites, certificate requirements, and HSTS configuration where applicable.
Encryption at rest should be documented per data store: database encryption technology and algorithm, file storage encryption, application secrets management, and any unencrypted data with explicit rationale. The security concept should make clear which data stores contain which classification levels and whether encryption is proportionate.
Key management practices complete the encryption picture: key generation and storage, rotation schedules, access controls (who can administer keys versus who can use them), emergency access procedures, backup and recovery, and legal hold considerations.
Monitoring and audit
Access control and data protection require monitoring to verify they work as designed:
The security concept should specify which events are monitored and forwarded to SIEM (authentication, authorisation, data access, privilege usage, encryption anomalies), what alerting thresholds apply for each event category, and audit log retention requirements aligned with regulatory obligations.
Common mistakes and how to avoid them
‘System implements strong authentication’ tells auditors nothing and gives implementers no guidance. Effective security concepts specify mechanisms: Azure AD SSO with MFA, session timeout 30 minutes, administrative access requires CyberArk elevation. This specificity enables verification and implementation.
Stating ‘System uses RBAC with roles: User, Admin’ identifies the pattern but not the permissions. Document a permission matrix showing exactly what each role can do, covering which API endpoints, which data operations, and which administrative functions. Authorisation matrices prevent privilege creep and enable audit.
‘Data encrypted at rest’ is compliance theatre. Specify encryption for each data store: database uses Azure SQL TDE with AES-256, keys in Key Vault; file storage uses Azure SSE; application logs remain unencrypted with PII masked. This granularity reveals actual protection and identifies gaps.
When systems can’t implement required controls, organisations often leave the gap undocumented, hoping auditors won’t notice. Effective security concepts document the standard control, explain the technical limitation, define the compensating control, and explicitly accept residual risk. This transparency enables informed risk decisions.
Documenting access controls without ongoing review processes creates decay. Security concepts should specify quarterly access review processes, role assignment approval workflows, and audit log monitoring procedures. Controls without maintenance become vulnerabilities over time.
Conclusion
Access control and data protection appear in every security concept. Getting the details right makes the difference between useful documentation and compliance theatre.
Document authentication requirements, not implementation. Specify authorisation models with role definitions and permission matrices. Classify data and define handling requirements. Specify encryption algorithms, key management, and what isn’t encrypted.
The goal: enough detail to enable design review, audit testing, and knowledge transfer without overwhelming readers with implementation specifics. Balance depth with usability.
Article 7 provides practical implementation guidance: document structure templates, getting started with first security concept, scaling to portfolio of systems, common pitfalls, and success patterns from organisations doing this well.
Next in series: Article 7 - Implementation Guide: Templates, Tools, and Getting Started
Article 6 of 7 | Ready for publication Target audience: Security Architects, System Architects, Technical Security Specialists Word count: ~2,350