ISO 27001 A.8.1–8.8: Technological Controls for Secure Systems

The technical foundation of Annex A

Controls A.8.1 through A.8.8 belong to the technological controls group in ISO 27001:2022. They address the fundamental technical measures every organization must implement, regardless of industry or size. For a company with around 100 employees, these controls are particularly relevant because they often cover the area where the IT department is already working — but which is not always systematically documented and managed.

The difference between "we sort of do that already" and "we have a documented process" is exactly what an auditor is looking for.

A.8.1: User Endpoint Devices

What the standard requires

Information stored on, processed by, or accessible through endpoint devices must be protected.

Implementation

Endpoint devices include laptops, desktops, smartphones, and tablets used by employees. They are the interface between people and systems — and thus one of the most common attack vectors.

Define device standards: Create a standard for endpoint device configuration. At a minimum, this covers: operating system version, full-disk encryption (BitLocker, FileVault), endpoint protection (antivirus/EDR), automatic updates, local firewall, and screen lock after inactivity.

Mobile Device Management (MDM): For companies with around 100 employees, an MDM system is advisable to enforce compliance with standards and enable centralized device management. Microsoft Intune, Jamf, or similar solutions are appropriate at this scale.

BYOD policy: If employees are allowed to use personal devices for work, you need a BYOD policy that defines minimum requirements (OS version, encryption, screen lock) and provides for remote wiping of corporate data.

Loss and theft: A documented process for when an endpoint device is lost or stolen. The process covers: reporting to IT, remote lock and potential remote wipe, assessment of what data was on the device, and potential classification as a security incident.

A.8.2: Privileged Access Rights

What the standard requires

The allocation and use of privileged access rights must be restricted and controlled.

Why this control matters so much

Privileged accounts (domain admin, root, database administrator, cloud admin) hold far-reaching permissions. A compromised admin account can take control of the entire network. Ransomware groups specifically target privileged accounts because a single compromised admin account can open access to all systems.

Implementation for around 100 employees

Separate admin accounts: Administrators use a normal user account for everyday tasks (email, browsing, document editing). They only use the admin account when actually performing administrative tasks. This sounds obvious, but in practice many companies have not implemented it.

Least privilege principle: Every account receives only the rights it actually needs for its tasks. A backup administrator does not need domain admin rights. A database administrator does not need access to the firewall.

Regular reviews: Privileged access rights are reviewed at least quarterly — ISMS Lite supports these reviews with automatic reminders and a documented approval workflow. Who has which rights? Do they still need them? Has their role changed?

Multi-factor authentication: MFA is mandatory for all privileged accounts. No exceptions.

Logging: All actions by privileged accounts are logged and regularly reviewed.

Password policy for admin accounts: Stricter requirements than for normal accounts: longer passwords, more frequent rotation (or better: a password manager with long, random passwords).

Just-in-time access: Ideally, privileged rights are not granted permanently but activated only when needed — and automatically revoked after expiration. For a company with around 100 employees, this may still be aspirational depending on the infrastructure, but it should be defined as a target.

A.8.3: Information Access Restriction

What the standard requires

Access to information and other associated assets must be restricted in accordance with the established topic-specific policy on access control.

Implementation

This control implements the access control policy (see A.5.1) at a technical level. The goal is that employees can only access the information they need for their work.

Role-based access control (RBAC): Define roles based on job functions and assign access rights to them. A sales representative has access to the CRM but not to accounting. An HR specialist has access to the HR system but not to the source code.

File system permissions: Network drives and file shares are structured by department or project, and access is restricted to authorized groups. No "everyone has full access to everything" shares.

Application permissions: In business applications (ERP, CRM, HR system), permissions are restricted to the functions required for the role.

Regular access reviews: At least annually, access rights of all employees are reviewed. Permissions that are no longer needed are revoked.

A.8.4: Access to Source Code

What the standard requires

Access to source code, development tools, and software libraries must be appropriately managed.

Relevance for a company with around 100 employees

If your company develops its own software or uses custom software, this control is relevant. If you exclusively use off-the-shelf software, it has lesser significance — but must still be addressed in the Statement of Applicability (SoA).

Access control for repositories: Source code resides in a version control system (Git), and access is restricted to the developers who need it.

Branch protection: Critical branches (main, production) are protected. Changes require code reviews and approvals.

No credentials in source code: Passwords, API keys, and other secrets belong in a secrets manager, not in source code.

A.8.5: Secure Authentication

What the standard requires

Secure authentication technologies and procedures must be implemented in accordance with information access restrictions and the topic-specific policy on access control.

Implementation

Enforce a password policy: Minimum length (12+ characters for normal accounts, 16+ for admin accounts), complexity requirements — or better: allow and encourage passphrases.

Multi-factor authentication: MFA for all externally accessible services (VPN, webmail, cloud services) and all privileged access. Ideally FIDO2/WebAuthn (hardware tokens) or TOTP (authenticator apps). SMS as a second factor is better than nothing but should be considered insecure.

Single Sign-On (SSO): Where possible, centralized identity management with SSO. This reduces the number of passwords employees must manage and enables centralized control of authentication.

Account lockout: After a defined number of failed login attempts, the account is temporarily locked. This prevents brute-force attacks.

No shared accounts: Every employee has their own credentials. Shared accounts (e.g., "admin" with a password known by three people) clearly violate the principle of accountability.

A.8.6: Capacity Management

A.8.6 requires that resource usage be monitored and adjusted to current and anticipated capacity requirements. This control is covered in detail in the article on A.8.9–8.16.

A.8.7: Protection Against Malware

What the standard requires

Protection against malware must be implemented and supported by appropriate user awareness.

More than just an antivirus scanner

Malware protection is a multi-layered topic. A standalone antivirus scanner is no longer sufficient in 2026. Modern attackers use techniques that evade classic signature-based scanners: fileless malware, living-off-the-land attacks, and polymorphic malware.

Endpoint Detection and Response (EDR): Instead of a classic antivirus scanner, an EDR system should be deployed that performs behavioral analysis and detects suspicious activity. For a company with around 100 employees, suitable solutions include Microsoft Defender for Endpoint, CrowdStrike Falcon Go, or SentinelOne.

Email filtering: An email gateway that scans attachments for malware, rewrites links in emails, and quarantines suspicious messages. Phishing emails remain the most common attack vector.

Web filter: Block access to known malware distribution sites and phishing domains.

Application whitelisting: On critical systems (e.g., servers), only allow execution of approved software. On endpoints this is harder to implement, but at minimum software installation should be restricted to administrators.

USB control: Restrict or technically prevent the use of USB storage devices, at least on systems with elevated protection requirements.

Awareness: Technical measures are complemented by employee training. Every employee must know how to recognize suspicious emails and what to do if they accidentally click a suspicious link.

A.8.8: Management of Technical Vulnerabilities

What the standard requires

Information about technical vulnerabilities of deployed information systems must be obtained in a timely manner, the organization's exposure to these vulnerabilities assessed, and appropriate measures taken.

The vulnerability management process

Step 1: System inventory: You can only assess vulnerabilities in systems you know about. A current inventory of all IT systems (servers, network devices, applications, cloud services) is the prerequisite.

Step 2: Identify vulnerabilities: Track vulnerability disclosures for your deployed systems and software. Sources include vendor advisories, CERT alerts (BSI CERT-Bund), and CVE databases. For companies with around 100 employees, an automated vulnerability scanner that regularly scans the network for known vulnerabilities is advisable (e.g., OpenVAS, Tenable Nessus, Qualys).

Step 3: Assess vulnerabilities: Not every vulnerability is equally critical. Assessment considers the CVSS score, exposure of the affected system (internal vs. externally reachable), availability of exploits, and the protection requirements of the data on the system.

Step 4: Take action: Apply patches, implement workarounds, or accept the risk (documented). Define SLAs for patch timelines based on criticality:

• Critical vulnerabilities (CVSS 9.0+, externally exposed, exploit available): 24–72 hours
• High vulnerabilities (CVSS 7.0–8.9): 7 days
• Medium vulnerabilities (CVSS 4.0–6.9): 30 days
• Low vulnerabilities (CVSS < 4.0): Next regular patch cycle

Step 5: Verify and document: After patching, verify that the vulnerability has actually been remediated. Document the entire process.

Typical audit findings for A.8.1–A.8.8

Finding 1: Administrators permanently work with admin accounts

IT administrators use their admin account for everyday tasks like email and browsing. A compromised admin account would have immediate full access to all systems.

How to avoid it: Set up a separate admin account for each administrator, used only for administrative tasks. The admin account has a different password and is used only when needed. Everyday work is done with a normal user account.

Finding 2: No documented vulnerability assessment

Patches are applied, but there is no documented process for vulnerability assessment. It is unclear what criteria are used for prioritization and whether critical vulnerabilities are addressed promptly.

How to avoid it: Create a documented vulnerability management process with clear roles, assessment criteria, and SLAs for patch timelines. Use a vulnerability scanner that regularly scans the network and generates reports.

Finding 3: Endpoints not uniformly configured

There is no defined standard for endpoint device configuration. Some laptops have full-disk encryption, others do not. Patch levels vary. No MDM system is in use.

How to avoid it: Define a baseline configuration for each endpoint type and enforce it through an MDM system. Regular compliance checks identify devices that deviate from the standard.

Finding 4: Privileged access rights not regularly reviewed

There is no documented review of admin rights. Former administrators still have admin access even though they have changed roles.

How to avoid it: Conduct a documented review of all privileged accounts at least quarterly. For each account, verify: Is the holder still with the company? Do they still need the rights? Are the rights appropriate? Document the results and decisions made.

Finding 5: No process for handling zero-day vulnerabilities

There is no defined escalation process for when a critical vulnerability becomes known for which no patch yet exists (zero-day). Workarounds and mitigation measures are decided ad hoc.

How to avoid it: Define an escalation process for zero-day vulnerabilities that specifies who is notified, who performs the risk assessment, what mitigation measures are considered (e.g., network segmentation, disabling affected services, additional monitoring), and who makes the decision on immediate actions.

How controls A.8.1–A.8.8 work together

The technological controls A.8.1 through A.8.8 are closely interconnected and should not be viewed in isolation. For example: endpoint security (A.8.1) requires malware protection (A.8.7), which in turn needs regular updates managed through vulnerability management (A.8.8). Secure authentication (A.8.5) is the foundation for access restriction (A.8.3), which in turn governs privileged access rights (A.8.2).

When you treat these controls as an interconnected system rather than isolated checklist items, implementation becomes more consistent and gaps between individual measures become visible. The auditor will check precisely this consistency: Does the malware protection strategy align with the endpoint policy? Does the vulnerability assessment match the defined patch SLAs? Do the privileged access rights align with the least-privilege principle of the access control policy?

For a company with around 100 employees, a pragmatic approach is recommended: Start with an inventory of your IT systems (without which no control works), then define baseline configurations (A.8.9, which formally falls under A.8.9–A.8.16 but conceptually belongs here), implement access control and privileged access rights, roll out malware protection, and build up vulnerability management. In this order, you create a solid foundation on which the remaining technological controls can build.

How ISMS Lite supports the evidence

Configuration standards: Document your endpoint configuration standards and assign them to the corresponding devices in the asset inventory.

Vulnerability management tracker: Capture vulnerabilities, map them to systems, document the assessment, and track remediation status. SLA breaches are displayed on the dashboard.

Privileged access register: Document all privileged accounts, their holders, and regular review results.

Access review workflow: Scheduled access reviews with notification, confirmation or revocation by the responsible party, and an audit trail.

Action tracking: All measures derived from the controls are centrally recorded and scheduled for follow-up.

Further reading

• Building vulnerability management: From detection to patching
• Patch management for SMEs: Process, prioritization, and automation
• Creating an authorization concept: Roles, rights, and recertification
• Implementing MFA in your organization: Strategy, tools, and rollout
• Network segmentation for SMEs: Protection against lateral movement