ISO 27001 A.8.24–8.34: Cryptography, Development, and Change Management

The final pieces of the technological puzzle

Controls A.8.24 through A.8.34 close out the technological controls section of ISO 27001:2022. They cover topics that are conceptually more demanding than the operational basics of A.8.1–A.8.16 but equally important for overall security.

For a company with around 100 employees, the good news is: not all of these controls carry equal relevance. If you don't develop your own software, the development controls (A.8.25–A.8.31) are less extensive to implement. But even then, you must address them in the Statement of Applicability (SoA) and justify why they have limited applicability in your context.

A.8.24: Use of Cryptography

What the standard requires

Rules for the effective use of cryptography, including the management of cryptographic keys, must be defined and implemented.

The cryptography policy

A.8.24 requires a documented cryptography policy. The key contents:

Approved algorithms: Define which algorithms may be used for which purposes. Guidance is provided by BSI TR-02102 and NIST recommendations.

Prohibited algorithms: DES, 3DES, RC4, MD5, and SHA-1 must no longer be used. Legacy systems that still use these algorithms need a documented migration plan.

Key management lifecycle: A lifecycle must be defined for cryptographic keys.

Generation: Keys are generated with cryptographically secure random number generators, not manually or with weak random sources.

Storage: Private keys are stored securely: in Hardware Security Modules (HSM), in protected key stores of the operating system (Windows Certificate Store, macOS Keychain), or in dedicated Key Management Services (AWS KMS, Azure Key Vault). Never in plaintext in configuration files or source code.

Distribution: Keys are distributed through secure channels. Public keys via certificates with a trusted CA. Private keys are never transmitted via email or messenger.

Rotation: Define rotation intervals. TLS certificates typically annually (or shorter with Let's Encrypt). Symmetric keys based on data volume and protection requirements.

Revocation: If a key is compromised, it must be immediately revoked and replaced. For certificates, via Certificate Revocation Lists (CRL) or OCSP.

Destruction: Keys that are no longer needed are securely deleted so they cannot be recovered.

Practical application

For a company with around 100 employees, the most common use cases for cryptography are:

• Transport encryption: TLS for websites, email (STARTTLS/SMTPS/IMAPS), VPN (IPsec or WireGuard)
• Storage encryption: BitLocker on Windows endpoints, FileVault on macOS, LUKS on Linux servers
• Email encryption: S/MIME or PGP for confidential emails
• Password hashing: bcrypt, scrypt, or Argon2 for stored passwords
• Backup encryption: AES-256 for backups stored offsite

A.8.25–A.8.27: Secure Development Lifecycle

A.8.25: Secure Development Life Cycle

The standard requires rules for the secure development of software and systems that cover the entire development lifecycle.

A.8.26: Application Security Requirements

Information security requirements must be identified, specified, and approved when applications are developed or acquired.

A.8.27: Secure System Architecture and Engineering Principles

Principles for secure system architecture and engineering must be established, documented, maintained, and applied to all information system development activities.

Implementation

If your company develops its own software (including internal tools, scripts, or automations), you need a Secure Development Lifecycle (SDLC). For a company with around 100 employees that typically has a small development team, a pragmatic approach is sufficient:

Security requirements in the requirements phase: For every new feature or system, security requirements are explicitly defined. What data does the system process? What are its protection requirements? What authentication is needed? What access rights?

Secure coding guidelines: Follow the OWASP Top 10 and define minimum requirements for secure code: input validation, parameterized database queries (against SQL injection), output encoding (against XSS), secure session management, no hardcoded credentials.

Code reviews: Every change to production code is reviewed by at least one other person before merging. Security aspects are part of the review criteria.

Automated security checks: Integrate Static Application Security Testing (SAST) and dependency scanning into the CI/CD pipeline. Tools like SonarQube, Snyk, or GitHub Dependabot are practical for small teams.

Separation of environments (A.8.31): Development, test, and production environments must be separated. Code is written in the development environment, tested in the test environment, and only deployed to production after approval. Developers have no direct write access to the production environment.

If you don't develop software

If your company exclusively uses off-the-shelf software, the development controls are relevant to a reduced extent. You still must ensure that security requirements are defined when procuring software (A.8.26) and that customizations (configurations, integrations, scripts) are performed securely.

A.8.28–A.8.29: Secure Coding and Testing

A.8.28: Secure Coding

Secure coding principles must be applied in software development. The standard refers to established frameworks such as OWASP guidelines and emphasizes the need to regularly train developers in secure programming.

A.8.29: Security Testing in Development and Acceptance

Security tests must be defined and performed in the development process. This includes:

Unit tests for security functions: Authentication, authorization, and input validation are specifically covered by tests.

Penetration tests: For critical applications, penetration tests before go-live and at regular intervals thereafter are advisable. For a company with around 100 employees, this can be done by an external service provider.

Acceptance tests with security criteria: When accepting new software or new releases, security criteria are explicitly verified.

A.8.30: Outsourced Development

When software development is outsourced to external service providers, the organization must direct and monitor information security activities in the outsourced development.

Contractual security requirements: The development contract must contain security requirements: secure coding guidelines, code ownership, access to source code, security testing, and vulnerability handling.

Code reviews: Externally developed code should also undergo a security review before being adopted into production.

Acceptance tests: Acceptance includes security tests performed by your organization or an independent third party.

A.8.33: Test Information

What the standard requires

Test data must be appropriately selected, protected, and managed.

The problem with production data in test environments

It is tempting to copy production data to the test environment because it is realistic and uncovers bugs that synthetic data misses. But production data often contains personal data, confidential business data, and financial information. When this data is copied to a less secure test environment, the risk of compromise increases.

Implementation

Anonymization/Pseudonymization: When production data is used in test environments, it must be anonymized or pseudonymized. Names, addresses, phone numbers, bank details, and other personal data are replaced with fictitious data.

Synthetic test data: Ideally, test data is generated synthetically. Tools like Faker (available for various programming languages) can produce realistic but fictitious datasets.

Access control for test environments: Even though test environments are less protected than production environments, they need access controls. Not every employee should have access to test data.

Deletion after testing: Test data is deleted after testing is complete when it is no longer needed.

Network segmentation and network management (A.8.20–A.8.23)

Although formally in a different numbering range, the network controls belong thematically in the context of the overall technological architecture.

A.8.22: Network Segregation

Network segmentation is one of the most effective measures against lateral movement of attackers within a network. The basic idea: divide the network into segments so that an attacker who has penetrated one segment does not automatically gain access to all others.

Minimum segmentation for around 100 employees:

• Server network: All servers in their own VLAN, separated from the user network
• User network: Employee endpoints
• Guest network: Wi-Fi for visitors, strictly separated from the internal network
• DMZ: Externally accessible services (web server, VPN gateway) in a demilitarized zone
• Management network: For administration of network devices and servers (optional but recommended)

Segments are separated by firewalls or access control lists (ACLs) on switches. Traffic between segments is filtered: only necessary communication is permitted.

A.8.23: Web Filtering

A.8.23 is a new control and requires that access to external websites be managed to reduce exposure to malicious content.

DNS-based filtering: A DNS filter (e.g., Cisco Umbrella, Cloudflare Gateway, Pi-hole with blocklists) blocks access to known malware domains, phishing sites, and other dangerous categories.

Proxy-based filtering: A web proxy filters HTTP/HTTPS traffic and blocks undesirable categories (malware, phishing, and potentially additional categories per company policy).

Category-based policies: Not everything needs to be blocked. Define categories that are blocked (malware, phishing, anonymizers) and categories that are allowed. Avoid overly restrictive filters that hinder employees in their work.

A.8.32: Change Management

What the standard requires

Changes to information processing facilities and information systems must be subject to a change management procedure.

The change management process

Change management has already been covered in a separate article. In the context of the technological controls, here are the key points:

Change types: Standard changes (pre-approved, low risk, e.g., regular patches), normal changes (individual assessment and approval), emergency changes (expedited procedure in case of acute danger).

Risk assessment: Every change (except standard changes) is assessed before implementation for its impact on information security — ISMS Lite provides the relevant controls with implementation recommendations and supports documentation through versioning and approval workflows. Which systems are affected? What risks arise? What measures reduce the risks?

Approval: Normal changes are approved by a defined approver or a Change Advisory Board (CAB). For a company with around 100 employees, the CAB can consist of IT management, the ISO, and the business unit owner.

Rollback plan: Every change needs a Plan B: What do we do if the change goes wrong? How do we restore the previous state?

Documentation: Every change is documented: What was changed? Why? Who approved it? When was it implemented? Was the implementation successful?

Post-implementation review: After implementation, verify whether the change achieved the desired effect and no unexpected side effects occurred.

A.8.34: Protection of Information Systems During Audit Testing

What the standard requires

Audit tests and other assurance activities involving operational systems must be planned and agreed between the tester and the responsible management.

Implementation

When internal or external audits include technical tests (vulnerability scans, penetration tests, configuration reviews), these must be coordinated to avoid jeopardizing ongoing operations.

Scheduling: Tests are performed outside core business hours if they could impact system availability.

Scope: The scope of testing is defined and agreed upon in writing beforehand. Which systems are tested? Which test methods are permitted? Which systems are excluded?

Access control: Testers receive only the access rights necessary for the test, which are revoked upon completion.

Documentation: Test results are treated as confidential and shared only with authorized persons.

Typical audit findings for A.8.24–A.8.34

Finding 1: No documented cryptography policy

Encryption is used, but there is no policy defining approved algorithms, key lengths, and the key lifecycle. Cryptographic decisions are implicit and not traceable.

Finding 2: No separation of development, test, and production

Developers have direct access to the production environment. There is no separate test environment, so changes are tested directly in production.

Finding 3: Production data in the test environment

The test environment contains a complete copy of the production database, including personal data and confidential business information, without anonymization.

Finding 4: Change management not followed in practice

A documented change management process exists, but in practice many changes are made without formal approval. Emergency changes are not documented retroactively.

Finding 5: No network segmentation

Servers, endpoints, and guest Wi-Fi are in the same network segment. A compromised endpoint has direct network access to all servers.

How ISMS Lite supports the evidence

Cryptography controls: ISMS Lite includes the relevant cryptography controls with practical implementation recommendations for algorithms and key lengths. With the built-in AI feature, you can generate a cryptography policy as a starting point.

Change management controls: The change management controls provide concrete recommendations for risk assessment, approval, and post-implementation review. Created documents are versioned and go through the approval workflow.

Development controls: Controls for secure development, coding guidelines, and testing procedures with practical recommendations for each phase of the development process.

Network controls: Controls for network segmentation, network management, and web filtering with implementation recommendations that you can use as a foundation for your network documentation.

SoA support: All 583 controls from 11 frameworks are mapped in ISMS Lite. For controls that have limited applicability in your context, you can document the justification directly in the Statement of Applicability.

Further reading

• Creating a cryptography policy: Algorithms, key lengths, and lifecycle
• Change management in the ISMS: Managing changes securely
• Network segmentation for SMEs: Protection against lateral movement
• Building vulnerability management: From detection to patching
• Creating an authorization concept: Roles, rights, and recertification