Access Control (Access Control)

Description of the measure according to ISO 27001/27002

Control A.5.15 requires that an organization implement rules and processes for controlling both physical and logical access to information and other business assets[1]. The goal is to implement a preventive security measure that ensures only authorized individuals and entities (such as software services or machines) gain access to sensitive data, systems and facilities[1]. Access control means in practice that access is based on business need and information security requirements[1].

According to ISO 27002:2022, A.5.15 includes different forms of access control: among others mandatory access control (MAC, centrally managed by one authority), discretionary access control (DAC, where owners themselves grant rights), role-based access control (RBAC, based on defined roles/functions) and attribute-based access control (ABAC, based on policy rules that combine attributes)[2][3]. Regardless of the chosen method, the standard emphasizes that access to resources may only be granted or modified on the basis of concrete business needs and security requirements[4]. This usually means applying the least privilege principle: users and systems are given only those access rights that are needed for their function or task[5].

Concretely, there must be an access control policy that describes the rules for granting, revoking and periodically reviewing access[6]. All relevant assets (information, systems) must be known and classified, so that access can be linked to the asset register and classification (including A.5.9 and A.5.12)[7]. Access is determined on the basis of need-to-know (functional role) or need-to-use (task-specific) to prevent someone from having unnecessary rights[8]. Roles and role-based access are recommended to promote efficiency and consistency (for example, a standard profile for an HR manager)[9]. Not only people are covered by this control, but also non-human identities such as service accounts, APIs and IoT/devices must fall under access control[10]. Furthermore, A.5.15 requires continuous periodic review of access rights (for example, annually or more often) to prevent privilege creep – the phenomenon where users over time unknowingly accumulate extra rights that are no longer needed[11]. Finally, the guidelines emphasize that access may not remain permanent and unevaluated: at regular intervals it must be checked whether someone's access rights are still justified.

Relevance for SMEs without their own security team

Access control is also a fundamental security measure for small and medium-sized organizations. Organizations without a dedicated security team or SOC in particular risk access management being handled informally or ad hoc. This can lead to situations where (former) employees, suppliers or systems have too much or uncontrolled access. In SME environments, employees often fulfill multiple roles, and without a strict policy one may be tempted to give users broad rights "for safety's sake". That goes against the least privilege principle and increases the chance of incidents.

In addition, SMEs often have limited IT staff, making formal procedures (such as demonstrable authorization when granting rights, or regular review of accounts) less obvious. Yet these controls are just as important for SMEs: many data breaches and security incidents arise precisely from simple access issues such as unauthorized accounts or too many people with admin rights. According to the Verizon Data Breach Investigations Report, compromised credentials remain the main cause of breaches – in 2023 stolen credentials were involved in about 50% of the investigated breaches[12]. These kinds of statistics apply not only to multinationals, but also to smaller companies: an attacker will, where possible, exploit poorly managed accounts or broad access rights.

Because SME organizations often do not have the resources for advanced detection, prevention through good access management is extra important. It prevents not only external attacks (a hacker finding an unused account), but also internal incidents (an unauthorized employee viewing sensitive data, or possibly even stealing it). In addition, customers, partners and auditors increasingly ask for evidence that smaller organizations also control access adequately. A clear, simple access policy and disciplined execution of it can build trust during an audit, even without a specialized team. In short, access control forms a first line of defense that is indispensable for every company – large or small.

Common shortcomings and overlooked points

Poor formal procedures: A frequently seen gap is the absence of a formal access control policy or process. In small organizations, access is arranged "on request via email or a phone call" without clear authorization or documentation. As a result, there is no audit trail: it cannot be shown who gave approval or whether a right was still needed. Training of staff in these procedures also falls short, causing people to bypass or forget the rules.

Not revoking rights when someone leaves: The biggest mistake is that accounts of departing employees or former third parties remain in place[13][14]. Auditors often call this a gotcha: for example, when they ask for a list of former employees and find that their VPN or application accounts are still active[15]. Not following a leaver process means that former employees sometimes still have access months later[16][13]. This is a serious security gap and low-hanging fruit for auditors to base a finding on. In addition, the organization may still be paying for accounts that no longer need to be active.

Privilege creep through account copies: Another mistake is cloning accounts for new employees ("give person X the same rights as Y, because they have a similar role"). This often leads to gradual privilege creep, where new users inherit all rights from their predecessor unnecessarily, including rights that are not relevant[17][18]. Especially when people change roles internally, old rights are sometimes retained if they are not explicitly removed when the role changes. Such cumulative rights are easily overlooked; compromise of such an account is a security disaster.

Third-party accounts that are always active: Access for suppliers or IT support is regularly left permanently active, even after the task is completed. For example, an external IT partner gets a generic account for maintenance and it is never disabled. Regular audits sometimes miss this, because the focus is on staff, while third-party access should also be periodically closed or reauthorized[19][20]. It is a bad sign if external consultants who finished months ago still have login access.

Excessive admin access: In smaller companies, it is common to see that a handful of users (or even everyone) has local admin rights on their PC, or that several people are given Domain Admin rights for convenience. This undermines segregation of duties. In addition, it is rarely logged who performs admin actions; often admin accounts are shared (for example, everyone uses the "Administrator" account). Auditors sometimes ask: "Show the members of the administrators group and explain who they are." In 9 out of 10 cases, admin accounts appear that had been forgotten, belonging to former employees or accounts whose origin is no longer known[21]. Such orphaned accounts or unexplained admin profiles are an immediate problem[21].

Gaps in periodic reviews: Although the policy often states that access rights must be reviewed annually or quarterly, this is often neglected in practice. Especially without a SOC, there is no continuous monitoring, and reviews are sometimes performed pro forma or not at all. As a result, outdated privileges remain unnoticed. What is often overlooked is the link between information classification and access: if there is no current classification scheme (A.5.12), it is not clear which information should be strictly restricted (A.8.3). In audits, this becomes apparent when, for example, confidential files are found on shared drives accessible to "All Employees", which goes against the need-to-know principle.

Examples of related incidents and vulnerabilities

Former employee with access sabotages systems: A stark example of not revoking access is the case of IT administrator Levi Delgado. This system administrator was fired by a medical center, but apparently retained his login credentials or a backdoor. Several months after leaving, he logged into his former employer's network, deleted large amounts of data and disabled user accounts[22][23]. This incident shows how disastrous it can be if a former employee still has access: business processes were brought to a halt and sensitive medical data may have disappeared. Such revenge attacks by former employees unfortunately occur regularly when the leaver process fails.

Unsecured LDAP access and anonymous queries: In some network environments, LDAP (directory service) allows anonymous users to perform queries. This is often a factory setting that has not been turned off. Attackers can abuse such anonymous LDAP binds for reconnaissance – they gather lists of users, groups and computers, which can help with targeted attacks[24][25]. In the worst case, this also means an immediate data breach because personal data about users may be exposed. Ransomware groups (such as BlackCat, LockBit and others) use this by running tools such as AdFind or SharpHound against Active Directory, often in an early stage of the attack[26][27]. If LDAP is accessible anonymously or with a low authentication level, such reconnaissance becomes very easy. This example emphasizes that restriction of access to information (A.8.3) does not only apply to files, but also to directory information: unauthorized reading of accounts must be prevented.

Abuse of admin rights by malware: Many successful cyberattacks escalate because attackers quickly manage to obtain administrative rights. In Windows environments, for example, attackers try to gain Domain Admin or local admin rights to enable lateral movement and widespread damage. Research showed that in 2023 several ransomware groups (including Akira, BlackSuit and BlackByte) used tools such as SharpHound and AdFind to scan Active Directory for highly privileged accounts and their permissions[28][27]. Once found, those accounts are taken over or abused for further infiltration. This underlines the importance of A.8.2 (restricting and monitoring privileged access): every admin account is a crown jewel for attackers. In addition, internal incidents such as the San Francisco network hostage situation show that disgruntled IT admins can "hold systems hostage" by withholding passwords or sabotaging changes[29]. The risk is real if there is no policy for shielding critical admin credentials or for a four-eyes principle on sensitive changes.

Private data made public due to lack of need-to-know: Another type of incident involves insufficient restriction of access to confidential information (A.8.3). A recent example is a government agency in Illinois that had internal map files containing personal data on a publicly accessible website. Due to incorrect privacy settings, sensitive data of 700,000 citizens was publicly accessible without authentication from 2021 to 2025[30][31]. It was only discovered after years, and access was then restricted. Such exposures also occur in business contexts, for example an HR folder on the network that is accidentally open to everyone, or a customer database in the cloud that is not shielded. Such incidents are often the result of failing to apply the need-to-know principle: no explicit decision has been made about who may not see what, so the default of "everyone may see everything" continues to apply.

Open S3 buckets and data breaches: Many organizations use cloud storage (such as Amazon S3 or Azure Blob) but configure access rights incorrectly. A notorious case involved the UK outsourcing company Capita in 2023. Capita left an Amazon S3 bucket containing about 655 GB of data unsecured on the internet for seven years[32]. There was no password or access restriction on this cloud storage, so anyone who knew the URL could access the files. The exposed data included software images, countless Excel and text files and even login credentials for internal systems[33][34]. This incident shows a painfully simple leak: a lack of basic measures to shield sensitive files. It directly illustrates the spirit of control A.8.3 (restriction of access to information): ensure that information is not accessible anonymously or publicly if it is not explicitly intended for publication[35]. Public cloud misconfigurations such as this have led to data breaches at multiple companies and are a favorite target for opportunistic attackers.

Source code theft through an insider threat: Where source code is the main intellectual property (in software companies), uncontrolled access to it can be disastrous. An example is the attack on a large software company in which a hacker group (LAPSUS$) managed to take over internal development accounts. In 2022, LAPSUS$ broke into Microsoft using a stolen employee login and obtained read access to countless internal Git repositories. They then leaked the source code of, among others, Bing and Cortana online[36][37]. Although Microsoft said that no increased risk arose from viewing the code, it does illustrate that a single compromised identity without strict access boundaries could gain access to enormous amounts of valuable source code. LAPSUS$ carried out similar attacks on other tech companies (Okta, NVIDIA, Samsung), sometimes stealing tens to hundreds of gigabytes of sensitive source code and data[38][39]. These incidents are directly linked to A.8.4 (access security for source code): insufficient restriction and monitoring of access to code makes it possible for an insider or external attacker to manipulate or steal business-critical software. Supply-chain attacks are also related to this – think of the SolarWinds attack, where a weak password on an update server and the lack of code integrity checks likely contributed to the ability to inject malicious code into their product[40]. In short, if source code security fails, this can lead to sabotage (malware in the code base) or theft of intellectual property with major damage to the organization and its customers.

Insufficiently secure login procedures: Many attacks start with weak authentication. A classic example is the hack on Colonial Pipeline in 2021. The attackers gained access to the infrastructure through an old VPN account that was still active without multi-factor authentication (MFA)[41]. Although the password itself was complex (so not "Colonial123"), one leaked password was enough to get in because a second verification step was missing[41][42]. This incident underlines that secure authentication (A.8.5) covers more than enforcing a strong password – without MFA or other additional controls, a stolen password is often enough to cause a crisis.

We see the same pattern on a smaller scale: many ransomware groups aim at RDP (Remote Desktop Protocol) or the VPN of SME companies, because these are often protected only by username and password. With simple password spraying or via password leaks, criminals regularly manage to gain access to such systems. According to security research, the majority of successful ransomware intrusions can be traced back to weak or stolen credentials (along with phishing)[12][43]. In a 2025 compliance study, it was even found that in about 70% of the cloud environments examined, the required MFA on admin accounts had not been implemented properly[44][45]. The result is that Control 5.17 (Authentication information) – which includes strong authentication for, among others, administrator accounts – was one of the most violated standards[45]. In other words: not having MFA on administrator accounts, for example, is now a direct nonconformity with the standard and an open door for attackers. This is a clear sign that even basic improvements in login security, such as MFA, can make a major difference in the threat level.

Recommendations for pragmatic implementation (SME)

For SME organizations, it is important to introduce the above controls pragmatically and step by step. Below we give recommendations per theme, focused on effectiveness with limited resources:

• Formulate a concise Access Policy: Establish a simple but clear access control policy (A.5.15) that fits the scale of your company. Record in it how accounts are requested and approved, who may grant authorizations (for example, managers for their team members), how often access rights are reviewed (at least annually), and how access is revoked when someone leaves. Keep it concise – a one-pager with a role-based access matrix and procedures is often sufficient. What matters is that management supports and communicates this policy, so everyone knows: granting access is a deliberate, documented action, not an ad hoc favor.
  
  

• Set up identity and access management processes: Implement the Joiner-Mover-Leaver principle (A.5.16 & A.5.18) using existing resources. Often HR or administration can maintain a list of new starters, internal role changes and leavers, which is reviewed periodically (weekly, monthly or quarterly, depending on the size of the organization) with IT. For each new employee (Joiner), determine before day 1 which accesses are needed, and have IT configure them after approval from the manager. When a role or function changes (Mover), revoke old rights before granting new ones. And when employment ends (Leaver), make sure that all access is deactivated on the last working day (or even within an hour after leaving, depending on sensitivity)[46]. The table below gives an example of such lifecycle actions and timing:

Practical example of lifecycle management of access rights (Joiner-Mover-Leaver)[46].

• Tools for identity management: Make use of existing platforms for basic identity management. Many SMEs use Microsoft 365 or Google Workspace – these already include functions for user and group management. Azure AD (for MS365) or Google Directory allow accounts to be managed centrally and access to linked apps to be controlled. Make use of these suites: define groups per function in Azure AD (for example, "Sales" gets CRM access) and let HR pass changes to IT so the correct group assignments are made. Consider Active Directory locally for Windows networks, possibly linked with Azure AD for cloud resources, so that offboarding works through one process. For very small organizations, a simple account list in Excel compared with HR data can already help ensure nothing is missed when someone leaves. The most important thing is overview: know which accounts exist (human and, importantly, do not forget non-human accounts either) and in which systems, so that no hidden accounts keep roaming around.
  
  

• Strict control of admin and special rights: Establish specific rules for privileged accounts (A.8.2). Limit the number of users with admin rights to an absolute minimum and apply the principle of segregation of duties: the person who requests or needs a certain access is not the same as the person who grants it[47]. Do not give normal users admin rights on their own workstation if it is not necessary. Where possible, use a separate administrator account per person alongside the normal user account, and use the admin account only for specific administrative actions. Such separation (admin versus user context) reduces the chance that a phishing email immediately yields full system rights.
  
  

• Just-In-Time and monitoring: For occasional administrative tasks, consider granting temporary access that automatically expires. In Microsoft Azure AD, for example, there is Privileged Identity Management (PIM) for just-in-time admin rights (available in certain licenses) – this may be too advanced or expensive for some SMEs, but the principle can be imitated manually: give an external administrator an account that is enabled only when needed and disabled again immediately afterward[48]. Also ensure that all logins to (domain) admin accounts are logged. Enable logging of Privilege Use events in Windows and collect log files (even if you only review them manually from time to time or use a low-cost logging solution). If an admin account logs in at 3 a.m., you want to notice quickly. For critical systems, you can set up login alerts (for example, an email or notification when the admin logs in).
  
  

• Secure local admin passwords: A practical tool for Windows environments is LAPS (Local Administrator Password Solution) from Microsoft, a free tool that keeps local administrator passwords (for example, the "Administrator" account on each PC) unique and stores them in AD, so the same admin password is not used everywhere. This prevents one leaked password from leading to full domain takeover. LAPS is a simple measure that shows during audits that admin credentials are handled consciously (relevant to A.5.17 and A.8.2).
  
  

• Restrict information access: Apply the need-to-know principle broadly (A.8.3). Review which shared folders, databases and applications exist and what sensitive data they contain. Then: segment access. For example: financial administration files accessible only to Finance staff; HR files only to HR, and so on. In cloud storage (OneDrive/SharePoint, Google Drive), use groups or shared drives to separate by department. Disable functions that allow data to be shared publicly without control: for example, prohibit sharing links "with anyone who has the link" for internal sensitive documents – choose "authenticated internal users only" instead. Check the public side of the website and cloud to see whether any files or APIs are open that should not be. Tip: regularly perform a simple open directory scan (or a Google search on your domain name and common file names) to detect whether internal information is findable via search engines. Also link the measure to classification: label confidential documents as such and implement technical restrictions (for example, DLP – Data Loss Prevention rules that prevent documents labeled "Internal Confidential" from being sent to external email or put on USB). Although DLP tooling can be expensive, Microsoft 365 and Google offer basic policies in some subscriptions that already let you begin (such as warnings when many personal data items are shared externally).
  
  

• Store and control source code securely: For A.8.4 (access to source code), the advice is to first use a version control system (for example git with a platform such as GitHub, GitLab or Bitbucket) instead of keeping code on network drives or separate computers. A cloud-based repo (private) immediately provides options to manage rights (only authorized developers have access) and log actions. Enable MFA on the repository platform for all users – GitHub now requires this for organizations. Set up role separation in the repository: not every developer needs write access to all projects; use read-only rights where applicable, and protect critical branches (such as the main/master branch) from direct commits by enabling mandatory code reviews. Code review by at least two people catches not only bugs, but can also detect malicious code insertions or unauthorized changes (four-eyes principle). Consider using digital signatures (code signing) for builds or scripts so that changes remain traceable and trustworthy afterward[49]. For software you release: use build pipelines that check authentication (CI/CD systems with limited access) and sign the final binaries. It is also wise to give external parties access to code only for a very limited time and scope. If you use freelance developers, create a separate account for each person and remove it as soon as the collaboration ends. Log checkout and commit activity – many platforms offer audit logs or at least a history per user. If an incident occurs (for example, sudden mass code exfiltration), you want to be able to see it and block the account immediately. Finally, do not store secrets (passwords, API keys) in code – use a separate secret vault or at least environment configurations outside the code repository. This prevents situations like SolarWinds, where a weak password was present in a repo[40]. There are free tools (for example, git-secrets or TruffleHog) that automatically scan repos for leaked secrets; you can integrate these into your development process as extra assurance.

• Strengthen authentication procedures: Implement secure authentication (A.8.5) on all your systems, with priority for externally accessible services and administrative access. Concretely: enable multi-factor authentication for all VPN, RDP, email, cloud and admin tools. For SMEs using Microsoft 365, this is easy to activate via Azure AD security defaults or Conditional Access (require MFA for all users or at least administrators). Many services offer free MFA options (mobile authenticator apps) that only need to be switched on. MFA is a quick win because it blocks more than 90% of attacks that rely only on passwords[50]. Especially for admin accounts, MFA is effectively required for compliance[51][52].

In addition, implement basic account security: where possible, enforce account lockout after a number of failed login attempts to prevent brute force attacks. Disable outdated, insecure protocols (for example, POP3/IMAP without SSL or old NTLMv1 logons) and allow only encrypted connections. Where possible, use SSO (Single Sign-On) solutions so that users do not need separate passwords everywhere – this makes authentication management more central and secure. For example, set your company Google or Microsoft account as the federation source for external applications that support it, so employees can log in everywhere with one trusted identity (and thus benefit from MFA and policy everywhere).

·         Password management and policy: Although MFA removes many risks, good password management remains essential (A.5.17). Apply a strong password policy that at minimum includes: minimum length (preferably ≥12 characters), prohibition of common passwords (you can use lists of breached passwords if desired), and encouragement for users to use passphrases instead of difficult short passwords. Avoid overly frequent mandatory resets (too frequent changes lead to weaker passwords or reuse patterns); focus instead on unique, long passwords and reset only when compromise is suspected. Provide employees with a password manager – there are affordable solutions such as LastPass Teams, 1Password Business, as well as open source options (Bitwarden). This helps them generate and securely store strong, unique passwords instead of on sticky notes or in unencrypted files. Also provide clear do's and don'ts around password use, for example via a user guideline or checklist.

An example of such a checklist is shown below, with good and bad practices for user authentication:

Checklist for handling authentication information safely[53].

These agreements can be provided as an appendix to the security policy or as a short e-learning module for staff. For SMEs, awareness is just as important as technical measures: one employee entering a password on a phishing site or accepting an unknown MFA prompt can break the whole chain. Training and simulations (for example, an occasional phishing test) help users stay alert.

• Change default credentials: Make sure that default passwords and accounts of all devices and software are changed or disabled immediately upon first use (A.5.17 requirement). Many SME devices (routers, NAS, cameras) come with admin/admin or a fixed PIN. When purchasing, inventory all default logins (the manual or a simple Google search usually lists them) and change them immediately to a unique, strong password. Make this part of the installation steps (for example, a checklist signed off by the IT reseller or internal IT)[54][55]. Weak or default credentials are a major risk and are easily avoided through diligence during installation.

• Set priorities: For SMEs without a large team, it is impossible to get everything perfect at once. Therefore set priorities based on risk.

  • Highest priority: close the biggest gaps first. This means: secure all privileged accounts with MFA (do it immediately, it costs little), disable/remove all unnecessary accounts (go through the list right away, a big clean-up), and change all default passwords. These are actions that can be started within days and immediately reduce risk dramatically.

  • Second priority: implement formal processes (joiner/leaver, periodic review) and define responsibility (who does what during onboarding/offboarding). This requires some discussion and documentation, but it prevents gaps from forming over time.

  • Third priority: further refinement such as setting up role-based access profiles, introducing an automated IAM solution if the scale requires it, or tools such as a SIEM-lite for log monitoring of critical accounts. These can be tackled later or as the organization grows.

The crucial point is to embed control measures in the normal business processes. If HR has a standard offboarding checklist that includes IT settings, account disabling will not be missed. If managers receive an email every quarter saying "check whether your employee list and their rights are still correct" and they only need to report exceptions, then the review is practical to carry out. Also look for synergy: a small IT service desk tool or even a SharePoint list can be used to track access requests and approvals, so you have evidence for audits.

Finally, do not underestimate the value of tailored external help: even without its own SOC, an SME can ask an external party to periodically review the user list and rights or perform a simple audit. This does not have to be expensive and provides an objective check. Some managed service providers offer "AD user cleanup" or security quick scans that perform exactly these controls. Having a fresh pair of eyes spot, for example, a forgotten admin account can prevent a major future vulnerability.

By introducing the above measures in phases, an SME organization can effectively comply with the ISO 27001:2022 controls in the area of logical access. The result is not only compliance on paper, but also demonstrably improved security: fewer accounts drifting around, clearer boundaries around who may access which information, and a greatly reduced chance that a simple password compromise leads to a serious incident. For smaller organizations, these investments in access security are highly worthwhile, given that the potential damage from a single incident can be many times greater than the cost and effort of getting the basic measures in order.

Sources: The content and recommendations in this report are based on the ISO/IEC 27001:2022 and ISO/IEC 27002:2022 standards and additional sources and cases, including best practice guides[1][56], security research[12][45] and reported security incidents from practice[32][22]. These references are included in the text for verification and further detail.

[1] [5] [6] [7] [8] [9] [10] [11] [13] [15] [16] [19] [20] ISO 27001 Annex A 5.15 Guide | Access Control

https://hightable.io/iso-27001-annex-a-5-15-access-control/

[2] [3] [4] ISO 27002, Control 5.15, Access Control | ISMS.online

https://www.isms.online/iso-27002/control-5-15-access-control/

[12] [43] Top 5 Insights from the Verizon DBIR 2023 - Axiom Security

https://axiom.security/top-5-insights-from-the-verizon-dbir-2023/

[14] [17] [18] [21] [46] [47] [48] [56] ISO 27001 Annex A 5.18 Guide | Access Rights & JML

https://hightable.io/iso-27001-annex-a-5-18-access-rights/

[22] [23] IT professional carries out a cyber-attack against former employer

https://cyfor.co.uk/it-professional-carries-out-a-cyber-attack-against-former-employer/

[24] [25] [26] [27] [28] LDAP Reconnaissance Explained | Semperis Identity Attack Catalog

https://www.semperis.com/blog/ldap-reconnaissance-explained/

[29] San Francisco Held Cyber-Hostage? Disgruntled Techies ... - WIRED

https://www.wired.com/2008/07/insider-tech-at/

[30] Illinois state agency exposed personal data of 700000 people

https://therecord.media/illinois-agency-exposed-data

[31] Illinois DHS reports data exposure from publicly accessible planning ...

https://chambanatoday.com/news/298892-illinois-dhs-reports-data-exposure-from-publicly-accessible-planning-maps/

[32] [33] [34] Security researcher finds trove of Capita data exposed online | TechCrunch

https://techcrunch.com/2023/05/05/security-researcher-finds-trove-of-capita-data-exposed-online/

[35] ISO27002:2022 - Controls - OnePager

https://asphalia-analytics.com/blog/posts/pdf/8.03%20-%20Information%20access%20restriction%20-%20OnePager.pdf

[36] [37] [38] [39] Microsoft Breach 2022! Product Source Code Compromised

https://www.stealthlabs.com/news/it-giant-microsoft-breached-products-source-code-compromised/

[40] SolarWinds hack explained: Weak password cause of SolarWinds Hack

https://specopssoft.com/blog/solarwinds-hack-weak-password-solarwinds123-cause/

[41] [42] One password allowed hackers to disrupt Colonial Pipeline, CEO tells senators | Reuters

https://www.reuters.com/business/colonial-pipeline-ceo-tells-senate-cyber-defenses-were-compromised-ahead-hack-2021-06-08/

[44] [45] [50] [51] [52] ISO 27002 - 5.17 : Why MFA for Cloud Admins Can’t Wait

https://www.unosecur.com/blog/iso-27002---5-17-the-mfa-rule-68-of-cloud-teams-still-fail

[49] 8.4 Access to Source Code for ISO 27002:2022

https://www.avisoconsultancy.co.uk/iso-27001-2022-annex-a/8-4-access-to-source-code

[53] [54] [55] ISO 27001 Annex A 5.17 Guide | Authentication Secrets

https://hightable.io/iso-27001-annex-a-5-17-authentication-information/