Article 25

Data Protection by Design and by Default

Article 25(1)

Taking into account the state of the art, the cost of implementation and the nature, scope, context and purposes of processing, as well as the risks of varying likelihood and severity for rights and freedoms of natural persons posed by the processing, the controller shall, both at the time of the determination of the means for processing and at the time of the processing itself, implement appropriate technical and organizational measures, such as:

• pseudonymization, which are designed to implement data-protection principles,

• data minimization, in an effective manner, and

• integration of the necessary safeguards into the processing

in order to meet the requirements of this Regulation and protect the rights of data subjects.

Article 25(2)

The controller shall implement appropriate technical and organizational measures for ensuring that, by default, only personal data which are necessary for each specific purpose of the processing are processed.

That obligation applies to the amount of personal data collected, the extent of their processing, the period of their storage and their accessibility. In particular, such measures shall ensure that by default personal data are not made accessible without the individual's intervention to an indefinite number of natural persons.

Article 28

Processor

Article 28(1)

Where processing is to be carried out on behalf of a controller, the controller shall use only processors providing sufficient guarantees to implement appropriate technical and organizational measures in such a manner that processing will meet the requirements of this Regulation and ensure the protection of the rights of the data subject.

Article 32

Security of Processing

Article 32(1)

[...] the controller and the processor shall implement appropriate technical and organizational measures to ensure a level of security appropriate to the risk, including inter-alia as appropriate:

• the pseudonymization and encryption of personal data;

• the ability to ensure the ongoing confidentiality, integrity, availability and resilience of processing systems and services;

• the ability to restore the availability and access to personal data in a timely manner in the event of a physical or technical incident;

• a process for regularly testing, assessing and evaluating the effectiveness of technical and organizational measures for ensuring the security of the processing.

9.1

Monitoring, measurement, analysis and evaluation

9.2

Internal audit

9.3

Management review

10

Improvement

A.8.1.3

Acceptable use of assets

Assets associated with information and information processing facilities shall be identified and an inventory of these assets shall be drawn up.

A.9.1.1

Access Control Policy

An access control policy shall be established, documented and reviewed based on business and information security requirements.

A.9.2.3

Management of privileged access rights

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

A.9.4.4

Use of privileged utility programs

The use of utility programs that might be capable of overriding system and application controls shall be restricted and tightly controlled.

A.12.4.1

Event logging

Event logs recording user activities, exceptions, faults and information security events shall be produced, kept and regularly reviewed.

A12.4.2

Protection of log information

Logging facilities and log information shall be protected against tampering and unauthorized access.

A.12.4.3

System administrator and system operator activities shall be logged and the logs protected and regularly reviewed.

A.12.6.2

Rules governing the installation of software by users shall be established and implemented.

A.12.7.1

Audit requirements and activities involving verification of operational systems shall be carefully planned and agreed to minimize disruptions to business processes.

A.14.2.1

Rules for the development of software and systems shall be established and applied to developments within the organization.

A.16.1.6

Learning from information security incidents

Knowledge gained from analyzing and resolving information security incidents shall be used to reduce the likelihood or impact of future incidents.

CC4.1

COSO Principle 16:

The entity selects, develops, and performs ongoing and/or separate evaluations to ascertain whether the components of internal control are present and functioning.

CC5.2

COSO Principle 11:

The entity also selects and develops general control activities over technology to support the achievement of objectives.

CC6.1

The entity implements logical access security software, infrastructure, and architectures over protected information assets to protect them from security events to meet the entity's objective.

CC6.3

The entity authorized, modifies, or removes access to data, software, functions, and other protected information assets based on roles, responsibilities, or the system design and changes, giving consideration to the concepts of least privilege and segregation of duties, to meet the entity's objectives.

CC6.6

The entity implements logical access security measures to protect against threats from outside its systems' boundaries.

CC6.7

The entity resticts the transmission, movement, and removal of information to authorized internal and external users and processes, and protects it during transmission, movement, or removal to meet the entity's objectives.

AC-1 Policy and Procedures

1. Develop, document, and disseminate:

   1. Access control policy that:

      1. Addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and

      2. Is consistent with applicable laws, executive orders, directives, regulations, policies, standards, and guidelines; and

   2. Procedures to facilitate the implementation of the access control policy and the associated access controls;

2. Designate an official to manage the development, documentation, and dissemination of the access control policy and procedures; and

3. Review and update the current access control:

   1. Policy (organization-defined frequency and following organization-defined events); and

   2. Procedures (organization-defined frequency and following organization-defined events).

Access control policy and procedures address the controls in the AC family that are implemented within systems and organizations.

The risk management strategy is an important factor in establishing such policies and procedures.

Policies and procedures contribute to security and privacy assurance. Therefore, it is important that security and privacy programs collaborate on the development of access control policy and procedures.

Security and privacy program policies and procedures at the organization level are preferable, in general, and may obviate the need for mission- or system-specific policies and procedures.

The policy can be included as part of the general security and privacy policy, or be represented by multiple policies reflecting the complex nature of organizations.

Procedures:

• can be established for security and privacy programs, for mission or business processes, and for systems, if needed.

• describe how the policies or controls are implemented and can be directed at the individual or role that is the object of the procedure.

• can be documented in system security and privacy plans or in one or more separate documents.

Events that may precipitate an update to access control policy and procedures include assessment or audit findings, security incidents or breaches, or changes in laws, executive orders, directives, regulations, policies, standards, and guidelines. Simply restating controls does not constitute an organizational policy or procedure.

AC-2 Account Management

1. Define and document the types of accounts allowed and specifically prohibited for use within the system;

2. Assign account managers;

3. Specify prerequisites and criteria] for group and role membership;

   1. Authorized users of the system;

   2. Group and role membership; and

   3. Access authorizations (i.e., privileges) for each account;

4. Require approvals by personnel or roles for requests to create accounts;

5. Create, enable, modify, disable, and remove accounts in accordance with policy, procedures, prerequisites, and criteria;

6. Monitor the use of accounts;

7. Notify account managers and personnel or roles within:

   1. time period when accounts are no longer required;

   2. time period when users are terminated or transferred; and

   3. time period when system usage or need-to-know changes for an individual;

8. Authorize access to the system based on:

   1. A valid access authorization;

   2. Intended system usage; and

   3. Other organization-defined attributes (as required);

9. Review accounts for compliance with account management requirements [Assignment: organization-defined frequency];

10. Establish and implement a process for changing shared or group account authenticators (if deployed) when individuals are removed from the group; and

11. Align account management processes with personnel termination and transfer processes.

Examples of system account types include individual, shared, group, system, guest, anonymous, emergency, developer, temporary, and service.

Identification of authorized system users and the specification of access privileges reflect the requirements in other controls in the security plan.

Users requiring administrative privileges on system accounts receive additional scrutiny by organizational personnel responsible for approving such accounts and privileged access, including system owner, mission or business owner, senior agency information security officer, or senior agency official for privacy.

Types of accounts that organizations may wish to prohibit due to increased risk include shared, group, emergency, anonymous, temporary, and guest accounts.

Where access involves personally identifiable information, security programs collaborate with the senior agency official for privacy to establish the specific conditions for group and role membership; specify authorized users, group and role membership, and access authorizations for each account; and create, adjust, or remove system accounts in accordance with organizational policies. Policies can include such information as account expiration dates or other factors that trigger the disabling of accounts.

Organizations may choose to define access privileges or other attributes by account, type of account, or a combination of the two. Examples of other attributes required for authorizing access include restrictions on time of day, day of week, and point of origin. In defining other system account attributes, organizations consider system-related requirements and mission/business requirements. Failure to consider these factors could affect system availability.

AC-2 (2) Account Management:

Automated Temporary and Emergency Account Management

Automatically remove and/or disable temporary and emergency accounts after a set time period for each type of account.

Temporary and emergency accounts are intended for short-term use. Organizations establish temporary accounts as part of normal account activation procedures when there is a need for short-term accounts without the demand for immediacy in account activation.

Organizations establish emergency accounts in response to crisis situations and with the need for rapid account activation. Therefore, emergency account activation may bypass normal account authorization processes.

Emergency and temporary accounts are not to be confused with infrequently used accounts, including local logon accounts used for special tasks or when network resources are unavailable (may also be known as accounts of last resort). Such accounts remain available and are not subject to automatic disabling or removal dates.

Conditions for disabling or deactivating accounts include when shared/group, emergency, or temporary accounts are no longer required and when individuals are transferred or terminated. Changing shared/group authenticators when members leave the group is intended to ensure that former group members do not retain access to the shared or group account. Some types of system accounts may require specialized training.

Management of temporary and emergency accounts includes the removal or disabling of such accounts automatically after a predefined time period rather than at the convenience of the system administrator. Automatic removal or disabling of accounts provides a more consistent implementation.

AC-2 (6) Account Management:

Dynamic Privilege Management

Implement organization-defined dynamic privilege management capabilities.

In contrast to access control approaches that employ static accounts and predefined user privileges, dynamic access control approaches rely on run-time access control decisions facilitated by dynamic privilege management, such as attribute-based access control.

While user identities remain relatively constant over time, user privileges typically change more frequently based on ongoing mission or business requirements and the operational needs of organizations.

An example of dynamic privilege management is the immediate revocation of privileges from users as opposed to requiring that users terminate and restart their sessions to reflect changes in privileges.

Dynamic privilege management can also include mechanisms that change user privileges based on dynamic rules as opposed to editing specific user profiles. Examples include automatic adjustments of user privileges if they are operating out of their normal work times, if their job function or assignment changes, or if systems are under duress or in emergency situations.

Dynamic privilege management includes the effects of privilege changes, for example, when there are changes to encryption keys used for communications.

AC-2 (7) Account Management:

Privileged User Accounts

1. Establish and administer privileged user accounts in accordance with either a role-based access scheme or an attribute-based access scheme;

2. Monitor privileged role or attribute assignments;

3. Monitor changes to roles or attributes; and

4. Revoke access when privileged role or attribute assignments are no longer appropriate.

Privileged roles are organization-defined roles assigned to individuals that allow those individuals to perform certain security-relevant functions that ordinary users are not authorized to perform.

Privileged roles include key management, account management, database administration, system and network administration, and web administration.

A role-based access scheme organizes permitted system access and privileges into roles.

In contrast, an attribute-based access scheme specifies allowed system access and privileges based on attributes.

AC-3 (2) Access Enforcement:

Dual Authorization

Enforce dual authorization for organization-defined privileged commands and/or other organization-defined actions.

Dual authorization, also known as two-person control, reduces risk related to insider threats. Dual authorization mechanisms require the approval of two authorized individuals to execute.

To reduce the risk of collusion, organizations consider rotating dual authorization duties. Organizations consider the risk associated with implementing dual authorization mechanisms when immediate responses are necessary to ensure public and environmental safety.

AC-3 (7) Access Enforcement:

Role-based Access Control

Enforce a role-based access control policy over defined subjects and objects and control access based upon organization-defined roles and users authorized to assume such roles.

Role-based access control (RBAC) is an access control policy that enforces access to objects and system functions based on the defined role (i.e., job function) of the subject.

Organizations can create specific roles based on job functions and the authorizations (i.e., privileges) to perform needed operations on the systems associated with the organization-defined roles. When users are assigned to specific roles, they inherit the authorizations or privileges defined for those roles.

RBAC simplifies privilege administration for organizations because privileges are not assigned directly to every user (which can be a large number of individuals) but are instead acquired through role assignments.

RBAC can also increase privacy and security risk if individuals assigned to a role are given access to information beyond what they need to support organizational missions or business functions.

RBAC can be implemented as a mandatory or discretionary form of access control. For organizations implementing RBAC with mandatory access controls, the requirements in AC-3 (3) define the scope of the subjects and objects covered by the policy.

AC-5 Separation of Duties

1. Identify and document organization-defined duties of individuals requiring separation; and

2. Define system access authorizations to support separation of duties.

Separation of duties addresses the potential for abuse of authorized privileges and helps to reduce the risk of malevolent activity without collusion.

Separation of duties includes dividing mission or business functions and support functions among different individuals or roles, conducting system support functions with different individuals, and ensuring that security personnel who administer access control functions do not also administer audit functions.

Because separation of duty violations can span systems and application domains, organizations consider the entirety of systems and system components when developing policy on separation of duties.

AC-6 Least Privilege

Employ the principle of least privilege, allowing only authorized accesses for users (or processes acting on behalf of users) that are necessary to accomplish assigned organizational tasks.

Organizations employ least privilege for specific duties and systems.

The principle of least privilege is also applied to system processes, ensuring that the processes have access to systems and operate at privilege levels no higher than necessary to accomplish organizational missions or business functions.

Organizations consider the creation of additional processes, roles, and accounts as necessary to achieve least privilege.

Organizations apply least privilege to the development, implementation, and operation of organizational systems.

AC-6 (1) Least Privilege:

Authorized Access to Security Functions

Authorize access for authorized personnel to carry out itemized security functions, with security-relevant information.

Security functions include establishing system accounts, configuring access authorizations (i.e., permissions, privileges), configuring settings for events to be audited, and establishing intrusion detection parameters.

Security-relevant information includes filtering rules for routers or firewalls, configuration parameters for security services, cryptographic key management information, and access control lists.

Authorized personnel include named individuals or roles such as security administrators, system administrators, system security officers, system programmers, and other privileged users.

AC-6 (2) Least Privilege:

Non-privileged Access for Non-security Functions

Require that users of system accounts (or roles) with access to itemized security functions and/or security-relevant information use non-privileged accounts or roles, when accessing non-security functions.

Requiring the use of non-privileged accounts when accessing non-security functions limits exposure when operating from within privileged accounts or roles.

The inclusion of roles addresses situations where organizations implement access control policies, such as role-based access control, and where a change of role provides the same degree of assurance in the change of access authorizations for the user and the processes acting on behalf of the user as would be provided by a change between a privileged and non-privileged account.

AC-6 (5) Least Privilege:

Privileged Accounts

Restrict privileged accounts on the system to organization-defined personnel or roles.

Privileged accounts, including super user accounts, are typically described as system administrator for various types of commercial off-the-shelf operating systems.

Restricting privileged accounts to specific personnel or roles prevents day-to-day users from accessing privileged information or privileged functions.

Organizations may differentiate in the application of restricting privileged accounts between allowed privileges for local accounts and for domain accounts, provided that they retain the ability to control system configurations for key parameters and as otherwise necessary to sufficiently mitigate risk.

AC-6 (6) Least Privilege:

Privileged Access by Non-organizational Users

Prohibit privileged access to the system by non-organizational users.

An organizational user is an employee or an individual considered by the organization to have the equivalent status of an employee.

Organizational users include contractors, guest researchers, or individuals detailed from other organizations. A non-organizational user is a user who is not an organizational user.

Policies and procedures for granting equivalent status of employees to individuals include a need-to-know, citizenship, and the relationship to the organization.

AC-6 (7) Least Privilege:

Review of User Privileges

1. Review at a predetermined frequency the privileges assigned to organization-defined roles or classes of users to validate the need for such privileges; and

2. Reassign or remove privileges, if necessary, to correctly reflect organizational mission and business needs.

The need for certain assigned user privileges may change over time to reflect changes in organizational mission and business functions, environments of operation, technologies, or threats.

A periodic review of assigned user privileges is necessary to determine if the rationale for assigning such privileges remains valid. If the need cannot be re-validated, organizations take appropriate corrective actions.

AC-6 (8) Least Privilege:

Privilege Levels for Code Execution

Prevent the listed software from executing at higher privilege levels than the logged-in users executing the software.

In certain situations, software applications or programs need to execute with elevated privileges to perform required functions. However, depending on the software functionality and configuration, if the privileges required for execution are at a higher level than the privileges assigned to organizational users invoking such applications or programs, those users may indirectly be provided with greater privileges than assigned.

AC-6 (9) Least Privilege:

Log Use of Privileged Functions

Log the execution of privileged functions.

The misuse of privileged functions, either intentionally or unintentionally by authorized users or by unauthorized external entities that have compromised system accounts, is a serious and ongoing concern and can have significant adverse impacts on organizations.

Logging and analyzing the use of privileged functions is one way to detect such misuse and, in doing so, help mitigate the risk from insider threats and the advanced persistent threat.

AC-6 (10) Least Privilege:

Prohibit Non-privileged Users from Executing Privileged Functions

Prevent non-privileged users from executing privileged functions.

Privileged functions include disabling, circumventing, or altering implemented security or privacy controls, establishing system accounts, performing system integrity checks, and administering cryptographic key management activities.

Privileged functions that require protection from non-privileged users include circumventing intrusion detection and prevention mechanisms or malicious code protection mechanisms.

Non-privileged users are individuals who do not possess appropriate authorizations. Preventing non-privileged users from executing privileged functions is enforced by AC-3.

AC-17 Remote Access

1. Establish and document usage restrictions, configuration/connection requirements, and implementation guidance for each type of remote access allowed; and

2. Authorize each type of remote access to the system prior to allowing such connections.

Remote access is access to organizational systems (or processes acting on behalf of users) that communicate through external networks such as the Internet. Types of remote access include dial-up, broadband, and wireless.

Organizations use encrypted virtual private networks (VPNs) to enhance confidentiality and integrity for remote connections. The use of encrypted VPNs provides sufficient assurance to the organization that it can effectively treat such connections as internal networks if the cryptographic mechanisms used are implemented in accordance with applicable laws, executive orders, directives, regulations, policies, standards, and guidelines.

Still, VPN connections traverse external networks, and the encrypted VPN does not enhance the availability of remote connections. VPNs with encrypted tunnels can also affect the ability to adequately monitor network communications traffic for malicious code.

Remote access controls apply to systems other than public web servers or systems designed for public access. Authorization of each remote access type addresses authorization prior to allowing remote access without specifying the specific formats for such authorization.

While organizations may use information exchange and system connection security agreements to manage remote access connections to other systems, such agreements are addressed as part of CA-3.

Enforcing access restrictions for remote access is addressed via AC-3.

AC-17 (1) Remote Access:

Monitoring and Control

Employ automated mechanisms to monitor and control remote access methods.

Monitoring and control of remote access methods allows organizations to detect attacks and help ensure compliance with remote access policies by auditing the connection activities of remote users on a variety of system components, including servers, notebook computers, workstations, smart phones, and tablets.

Audit logging for remote access is enforced by AU-2. Audit events are defined in AU-2a.

AC-17 (2) Remote Access:

Protection of Confidentiality and Integrity Using Encryption

Implement cryptographic mechanisms to protect the confidentiality and integrity of remote access sessions.

Virtual private networks can be used to protect the confidentiality and integrity of remote access sessions. Transport Layer Security (TLS) is an example of a cryptographic protocol that provides end-to-end communications security over networks and is used for Internet communications and online transactions.

AC-17 (3) Remote Access:

Managed Access Control Points

Route remote accesses through authorized and managed network access control points.

Organizations consider the Trusted Internet Connections (TIC) initiative DHS TIC requirements for external network connections, since limiting the number of access control points for remote access reduces attack surfaces.

AC-17 (4) Remote Access:

Privileged Commands and Access

1. Authorize the execution of privileged commands and access to security-relevant information via remote access only in a format that provides assessable evidence and for organization-defined needs; and

2. Document the rationale for remote access in the security plan for the system.

Remote access to systems represents a significant potential vulnerability that can be exploited by adversaries.

As such, restricting the execution of privileged commands and access to security-relevant information via remote access reduces the exposure of the organization and the susceptibility to threats by adversaries to the remote access capability.

Article 9 (3) (a)

In order to achieve the objectives referred to in paragraph 2, financial entities shall use ICT solutions and processes that are appropriate in accordance with Article 4. Those ICT solutions and processes shall:

• ensure the security of the means of transfer of data.

Article 9 (3) (b)

In order to achieve the objectives referred to in paragraph 2, financial entities shall use ICT solutions and processes that are appropriate in accordance with Article 4.

Those ICT solutions and processes shall:

• minimise the risk of corruption or loss of data, unauthorised access and technical flaws that may hinder business activity.

Article 17

Full article

Article 10

Full article

Paragraph 49

Cyber hygiene policies provide the foundations for protecting network and information system infrastructures, hardware, software and online application security, and business or end-user data upon which entities rely.

Cyber hygiene policies comprising a common baseline set of practices, including software and hardware updates, password changes, the management of new installs, the limitation of administrator-level access accounts, and the backing-up of data, enable a proactive framework of preparedness and overall safety and security in the event of incidents or cyber threats.

ENISA should monitor and analyze Member States’ cyber hygiene policies.

Paragraph 54

In recent years, the Union has faced an exponential increase in ransomware attacks, in which malware encrypts data and systems and demands a ransom payment for release.

The increasing frequency and severity of ransomware attacks can be driven by several factors, such as different attack patterns, criminal business models around ‘ransomware as a service’ and cryptocurrencies, ransom demands, and the rise of supply chain attacks.

Member States should develop a policy addressing the rise of ransomware attacks as part of their national cybersecurity strategy.

Paragraph 85

Addressing risks stemming from an entity’s supply chain and its relationship with its suppliers, such as providers of data storage and processing services or managed security service providers and software editors, is particularly important given the prevalence of incidents where entities have been the victim of cyber attacks and where malicious perpetrators were able to compromise the security of an entity’s network and information systems by exploiting vulnerabilities affecting third-party products and services.

Essential and important entities should therefore assess and take into account the overall quality and resilience of products and services, the cybersecurity risk-management measures embedded in them, and the cybersecurity practices of their suppliers and service providers, including their secure development procedures.

Essential and important entities should in particular be encouraged to incorporate cybersecurity risk-management measures into contractual arrangements with their direct suppliers and service providers. Those entities could consider risks stemming from other levels of suppliers and service providers.

Paragraph 89

Essential and important entities should adopt a wide range of basic cyber hygiene practices, such as zero-trust principles, software updates, device configuration, network segmentation, identity and access management or user awareness.

These entities should also schedule regular training for their staff and raise awareness concerning cyber threats, phishing or social engineering techniques.

Furthermore, the entities should evaluate their own cybersecurity capabilities and, where appropriate, pursue the integration of cybersecurity enhancing technologies, such as artificial intelligence or machine-learning systems to enhance their capabilities and the security of network and information systems.