Consider an organization adopting artificial intelligence (AI) as being represented by a self-driving car. Data serve as gasoline, which provides the driving force to the car; machine learning (ML) is the engine, which determines the performance of the car; and AI operates as the role of the sensor in the car, contributing to the process of automatic decision-making. A self-driving car with good performance requires more data input to obtain continuous driving force to become more competitive and make more accurate analysis and predictions. However, especially for an Internet finance organization, multiple relational datasets can easily result in “isolated islands of information,” which make it difficult to connect the datasets where they can talk to each other.
How to implement data sharing effectively without violating EU General Data Protection Regulation (GDPR) provisions becomes one of the biggest concerns of AI GDPR compliance. The following are questions answered in my recent Journal article:
- Will GDPR result in the prohibition of AI for use with EU individuals’ data?
- How does one obtain informed consent for an AI algorithm that cannot explain its decision-making criteria?
- If a user opts out, is an alternative human-based decision system available?
In my recent article, I explain the main conflicts between AI and GDPR (figure 1).
AI vs. GDPR
Reference GDPR Provisions
Accuracy of automated decision-making
Obtain human intervention and do not rely solely on a machine
Use data accuracy analysis technology—monitor the AI agent performance and use ML to increase the accuracy
Conduct a data protection impact assessment (DPIA) and trustworthy AI assessment
Conduct rigorous testing, e.g., penetration tests and cybersecurity control assessments
Ensure traceability, auditability and transparent communication on system capabilities
Article 4(4), Article 9, Article 12, Article 13, Article 14, Article 15, Article 21, Article 22, Article 35(1) (3)
The Right to Erasure
Article 6, Article 9, Article 12, Article 17, Recital 65, Recital 66
Article 5(1)(c), Recital 39, Article 16, Article 17
Use metadata management tools: data governance to authorize specific person accessing the specified data link terminal (DLT)
Have a specific privacy notice and explicit consent
Use a differential privacy model; delete personally identifiable information (PII) without modifying the meaning of datasets
Article 5, Article 12, Article 13, Article 14
Read Andrea Tang's recent Journal article:
"Making AI GDPR Compliant," ISACA Journal, volume 6, 2019.
Compliance procedures are notoriously demanding, and European Union General Data Protection Regulation (GDPR) compliance programs are no different. My recent Journal article underlined some of the challenges that may be experienced by organizations as they try to meet GDPR requirements and introduced a series of steps that organizations can take to help them in their GDPR compliance journey.
Arguably, one of the integral first steps is developing and maintaining a record of processing activities undertaken by the organization.1 This will help in understanding:
- The categories of personal data being processed
- The categories of processing being undertaken
- The external and internal flows of personal data throughout the organizational ecosystem
- The key accountabilities associated with processing
- The risk associated with processing
Article 30 of the GDPR requires that an organization, whether a controller or processor, must maintain proper record of processing activities under their responsibility. Therefore, your organization must maintain a record if it carries out certain operations or set of operations on the personal data under its responsibility. This may include collecting customer demographic details, recording employees’ personal information or other types of operations.
Your record must be in writing, including electronic form, and made available to the supervisory authority on request.
For these reasons, your record should be current, complete and accurate at all times and in a form suitable for scrutiny.
The obligation to maintain a record may not apply if your organization employs less than 250 persons. However, this exception does not apply if your processing activity:
- Is likely to result in a risk to the rights and freedoms of data subjects. Therefore, if your customer records are stored with a cloud services provider, for example, this form of processing may be viewed as a risk.
- Is not occasional. This could mean that once your processing is not random or rare, then a record of processing activities is required.
- Includes special categories of data, such as personal data revealing racial or ethnic origin, political opinions, religious or philosophical beliefs, or other special categories referred to in Article 9(1).
- Includes personal data relating to criminal convictions and offenses as referred to in Article 10.
Based on the foregoing, it may be best that your organization errs on the side of caution and maintain a record of its processing activities.
The obligations in relation to the details of the record differ between a controller and processor. Common among them, however, are the requirements to maintain:
- A description of the technical and organizational security measures undertaken to minimize the risk to processing
- Details relating to transfers of personal data to a third country or an international organization
- The name and contact details of your organization, or its representative, and your data protection officer
Knowing the extent of your processing activities will greatly assist your organization as it moves forward in its GDPR compliance program.
Read Corlane Barclay’s recent Journal article:
“The Road to GDPR Compliance: Overcoming the Compliance Hurdles,” ISACA Journal, volume 1, 2019.
1 This article assumes that an organization falls within the scope of GDPR. For further discussion on the scope of GDPR, please see my Journal article.
Whether from a conformance (compliance) or performance perspective, 2 enterprise governance tasks of particular interest are:
- Knowing what questions to ask in the process of performing due diligence
- Knowing what data and information to request to support the due diligence process
In the case of compliance, the extent of the information required to support due diligence is proportional to the impact of the risk of noncompliance to the organization. In the case of the EU General Data Protection Regulation (GDPR), the risk factors associated with noncompliance are extraordinary. At a minimum, the risk poses challenges not only in terms of the considerable maximum penalties for noncompliance, but, perhaps more importantly, also in terms of the reputation impact of noncompliance.
The latter issue is an outcome of the likelihood that any financial penalties imposed due to noncompliance are certain to make headline news, communicating to everyone that the organization has not yet met its obligations to protect the privacy of EU natural persons in spite of the fact that the regulation has been in effect since May 2018.
A board director recently suggested that the only information the board required for GDPR compliance progress monitoring is:
- What is the exposure to the risk of noncompliance?
- What is the progress toward achieving compliance?
In this case, the director’s argument was that sufficient reporting would merely contain a statement to the effect that the exposure was up to €2 million (US $2.3 million) or 4% of global revenues, coupled with an overview of the compliance project’s progress to plan.
However, a director on the same board specifically overseeing enterprise risk management (ERM) instead suggested that the board required more detail than what was proposed previously in the interests of appropriate due diligence. In particular, the board not only required better knowledge of the regulation, but also greater insight with respect to the extent of the organization’s efforts toward achieving compliance with the different components of this complex regulation.
Becoming knowledgeable of the regulation enabled the board to ask better questions in its obligation to perform oversight and to better understand the different components of the regulation that applied to the organization. In further response to the ERM director’s recommendation, a reporting framework was structured to provide more detail than would have been presented at a project overview level, to enable more directors to understand the nature of the work being performed for compliance and what parts of the operating model (people, process or technology) were impacted. At a glance, the framework enabled insights into the progress of achieving compliance against plan for identified components of GDPR and also of the relative progress of these activities relative to the activity of the prior reporting period.
Given this background, my recent Journal article documents high-level aspects of the approach taken—perhaps useful for organizations that have not yet fulfilled their GDPR obligations—to leverage for their own purposes.
Read Guy Pearce’s recent Journal article:
“Reporting on GDPR Compliance to the Board,” ISACA Journal, volume 1, 2019.
Practical implementation and management of data loss prevention or protection (DLP) solutions or a portfolio of solutions should follow a logical process to ensure the holistic protection of information resources. Strategies intended to protect information resources should span the 3 generic domains of people, processes and technologies.
Understand the Business Layout
Implementers and managers of DLP solutions first need to understand the business layout of the institution requiring protection, which entails understanding the organization’s information strategy. An information strategy highlights the organization’s valuable or business-critical information and how the organization intends to use said information to add value. Further to identifying the organization’s critical information, protectors need to understand how the information flows between the various units of the organization, including external parties. The various technologies that process information should be identified, and protection profiles should be defined for each technology class. The COBIT 5 Goals Cascade can help translate the organization’s information goals into a technical protective profile.
Develop a Culture of Information Ownership
Every piece of information within the organization should be traceable to a business owner who is responsible and accountable for its usage and protection. Practically speaking, the information owner is normally a business unit head or someone senior enough to decide the usage of information resources. Ideally, information owners do not have the technical expertise to implement security measures; they normally rely on system owners (i.e., individuals responsible for the computers that house the information) and custodians (i.e., individuals with hands on expertise of data management to ensure resources are protected).
Implement Protective Measures
To ensure a holistic approach, guardians of information resources should avoid a one-solution or silver bullet approach as information exists in multiple states. The various aspects of information, including the people, the processes and the technology, need to be aligned in a manner that supports the achievement of organizational objectives. The defense-in-depth (DiD) model (figure 1) provides a practical approach to this endeavor.
Figure 1—Defense in Depth
COBIT 5 Enablers (figure 2) also provides practical support to this effort by identifying key components of the information ecosystem.
Figure 2—COBIT 5 Enablers
Source: ISACA, COBIT 5, USA, 2012. Reprinted with permission.
Keep the Momentum Going
The protection of information resources is a living, active process requiring continuous monitoring and improvement. A good understanding of the organization’s information strategy enables respective guardians to develop and maintain a risk management program that ensures the continued protection of information resources.
Read Christopher Nanchengwa’s recent Journal article:
“The Four Questions for Successful DLP Implementation,” ISACA Journal, volume 1, 2019.
The EU General Data Protection Regulation (GDPR) outlines measures required to protect personal data and how an enterprise moves, uses and stores that data. My recent ISACA Journal article, “Protection From GDPR Penalties With an MFT Strategy,” discusses why a robust managed file transfer (MFT) and integration platform is useful for organizations looking to comply with GDPR and other data protection measures.
Here are some key steps for implementing an MFT solution to meet increasingly stringent data demands:
Assess your ecosystem—It is difficult for any organization to understand all the systems and applications deployed across departments and geo-distributed locations. But it is important to understand them and the life cycle of business data to ensure GDPR compliance. A comprehensive enterprisewide assessment of every on-premise and cloud system, database, application, and storage repository is critical in determining how MFT can streamline data processing.
Evaluate your best deployment architecture—Understanding the data flows and systems that will be exchanging data, along with your other architectural components, will help define the best deployment architecture for your MFT solution. Depending on the nature of your data exchanges, an on-premise, cloud or hybrid solution may enable the best control. Also, the ability to integrate with central authentication and auditing systems may be important, as might the ability to deploy as part of a broader development operations (DevOps)-driven environment.
Select the software—There are numerous MFT vendors out there. Smart organizations, however, know exactly what questions to ask an MFT vendor before selecting a solution that may not even fit the business needs.
Design the service—The project manager often will liaise with the vendor for the bulk of this work, but that person also must seek input from other personnel (i.e., enterprise architect, security and compliance managers, application analyst) to ensure that all the required business functionality, IT administration and security boxes are checked.
Test, test, test—After you have captured the service flows, configure the system, partner profiles and firewall connections, and throw everything you can at it. This quality assurance period is critical to outlining each required (and potential) use case and data pattern.
Deploy and support—The time between testing and production is critical because it is when operational challenges surface. Solicit your vendor’s professional services team to help with migration and implementation requirements and lean on their support teams to resolve issues upon deployment.
Read Dave Brunswick’s recent Journal article:
“Protection From GDPR Penalties With an MFT Strategy,” ISACA Journal, volume 4, 2018.
In recent years, board-level supervision in information technology matters has become a key IT governance topic. It is often assumed that national corporate governance codes can guide board members to design and potentially improve their IT governance practices. At the Antwerp Management School (AMS), we conducted a study to understand what IT governance-related guidelines are included in national corporate governance codes.
We selected 15 national corporate governance codes to study. These codes were selected based on income level and geographic dispersion across different continents. Surprisingly, we found that most national corporate governance codes do not include key IT governance topics. There is hardly any IT governance information incorporated in the codes at all. The only exception we found was the South African corporate governance code, King III, which contains an entire chapter on IT governance-related guidelines. We also note that the committee responsible for drafting the South African corporate governance code recently finalized King IV, in which IT-related matters assume an even more prominent role. Based on our findings, we conclude that:
- Corporate governance committees responsible for drafting corporate governance codes worldwide that are willing to recognize the value of IT governance can certainly benefit from looking at the South African corporate governance codes.
- Additionally, we suggest that board members who are already complying with their existing national corporate governance codes refer to the King III guidelines to explore more concrete guidelines on IT governance.
This study was performed by researchers at AMS around an industry-sponsored research project on board-level IT governance. The research project focused on the need for boards to extend their governance accountability from a mono-focus on finance and legal as proxy to corporate governance. This extended accountability should include technology and provide digital leadership and organizational capabilities to ensure that the enterprise’s IT department sustains and extends the enterprise’s strategies and objectives. We discovered that board members are increasingly seeking guidance on how they can expand their IT governance accountability within the board and also in an appropriate modus vivendi with executive management. More information, including intermediary results, can be found on the AMS website.
Read Steven De Haes, Anant Joshi, Tim Huygh and Salvi Jansen’s recent Journal article:
“Exploring How Corporate Governance Codes Address IT Governance,” ISACA Journal, vol. 4, 2017.
In Canada, it is the Data Privacy Act and its impact on the Personal Information Protection and Electronic Documents Act (PIPEDA); in the United States, the regulations include the Gramm-Leach-Bliley Act, the Health Insurance Portability and Accountability Act (HIPAA), and the US Personal Data Notification and Protection Act; in Australia, it is the Privacy Amendment Act, while in the EU, it is the ePrivacy Directive. There are more regulations than those previously listed. In common with each is the growing requirement for privacy breach reporting, with breach assessment being a major part of that process. This includes identifying the location of the breach, the type of data that have been compromised and identifying exactly who could be compromised by the breach, since they would need to be individually notified in case of a breach of their sensitive data.
Now, large corporations, especially banks, but also insurers and financial securities organizations, have invested heavily in various forms of enterprise data management (EDM) tools and processes since the publication of the Basel Committee on Banking Supervision’s (BCBS) Principles for Effective Risk Data Aggregation and Risk Reporting (RDARR) in 2013. More recently, the data management implications of BCBS 265, fundamental review of trading book, are coming to light, with much in common with RDARR from a data aggregation perspective.
Cyber security practitioners are already familiar with data classification frameworks for the sensitivity of various enterprise data artifacts. However, the very EDM tools mentioned previously readily facilitate more classification detail, such as whether data constitute personally identifiable information (PII), payment card industry (PCI) data or personal health information (PHI), or, at a lower level, even whether the data are passport data, insurance numbers or credit card numbers.
By classifying more enterprise data, they become easier to locate, e.g., identify all data sources across the enterprise with passport numbers. Critically, it also becomes easier and faster to identify all the data classifications that are exposed at the point of breach. This drives the level of detail required in the breach report and the nature of the post-breach actions, all serving to simplify post-breach planning. Note that data classification is already happening, often implicitly, as part of many different enterprise data profiling activities within the EDM team.
From a cyberrisk mitigation perspective, data classification is an enterprisewide initiative, since a breach could happen anywhere. For those organizations with the foresight to implement true enterprisewide data management as a follow-on, e.g., from RDARR, it makes sense for the cyber security team to leverage these EDM investments and learnings for cyberrisk management purposes. This not only makes good sense to the chief financial officer, it also means a quicker time to deployment and quicker time to breach reporting, all of which is good news for compliance, and really good news for us, the public.
Read Guy Pearce’s recent Journal article:
“Boosting Cyber Security With Data Governance and Enterprise Data Management,” ISACA Journal, volume 3, 2017.
The Authority to Operate (ATO) is necessary to work in the system of US federal government agencies. My recent Journal article provides details on how to obtain the authority to operate. The following steps can help US enterprises gain the approval to operate with the federal government:
● Ensure confidentiality, integrity and availability—The first necessary step toward achieving ATO is confidentiality, integrity and availability (CIA). This means that only approved people can get in, any changes to the system or data are genuine, and the system is up and ready for use.
● Embrace the NIST 800-53 control families—Every family is a tightly knit assembly of control with a dash-one, or parent control, followed by offspring controls that dive deep into the security measure. For instance, the Access Control Family starts with the dash one control of access control policy. It is followed by more detailed controls to be implemented and assessed such as Account Management and Access Enforcement. Using the lists of controls within each of the 18 NIST control families allows users to demonstrate security that is in place or that it is being planned.
● Keep the evidence—Just like in any operational process, you create or gather documentation to delineate the process and what has taken place. Just like any trail or audit, you keep evidence of the path you have taken. The ATO process allows you to gather and store all the security documentation. This serves well in building a case for the security posture of your system and how it fits into your federal agency’s risk profile.
In addition to these steps, following the US National Institute of Standards and Technology Risk Management Framework can help your system be granted with the ATO.
Read Jo Anna Bennerson’s recent Journal article:
“Navigating the US Federal Government Agency ATO Process for IT Security Professionals,” ISACA Journal, volume 2, 2017.
We are living in a digital world where a staggering number of data breaches have resulted in the theft of personal data of end users across a broad spectrum of sectors, such as financial, health care and media. The growing adoption of the cloud, mobile devices and social media has resulted in an increase in incidents related to the theft of personal data.
As organizations begin the scramble to comply with the European Union (EU) General Data Protection Regulation (GDPR), there is a dire need to understand its scope and the privacy requirements mentioned in the standard. The regulation is applicable to all organizations that store, process and transmit any personal data related to an EU resident. The GDPR will replace Directive 95/46/EC, which has been the basis of European data protection law since it was introduced in 1995. The regulation will apply to even those organizations that may not have a presence in the EU, but are processing or accessing the personal data of EU data subjects.
There are an overwhelming amount of privacy requirements that an organization has to consider to enhance its privacy management program, mitigate privacy risk and demonstrate adherence to the GDPR. The following should be considered when developing policy to comply with the privacy requirements of the GDPR program:
- Organizations must have commitment and support from the leadership and a consensus to successfully implement the GDPR compliance.
- Conduct an awareness campaign so that everyone understands the seriousness and importance of the new privacy law, which will be become enforceable in May 2018.
- Resources and budget will be required to develop the complete roadmap to achieve compliance with the GDPR.
- Noncompliance with the GDPR results in enormous fines for both the data controller and the data processor.
- There are strict conditions for privacy notices and obtaining consent.
- Pseudonymisation of data, which involves processing personal data without identification of the subject, is necessary.
- Understand and implement the new privacy requirements, such as privacy by design, right to erasure, right to portability, mandatory privacy impact assessments, data breach notification and appointment of a data protection officer (DPO).
- There are enhanced obligations for data processors.
It is imperative for organizations to proactively determine their current state of data protection and benchmark it with GDPR requirements to understand whether they are GDPR compliant and identify which gaps must be filled. To bring themselves in line with the GDPR, companies both inside and outside the EU will be required to consider the changes required in the way they interact with customers and the transfer of data. It also means organizations have to invest more on the tools and technologies required to ensure adherence to stringent privacy requirements of GDPR.
Tarun Verma is a senior consultant with Infosys-Information and Cyber Risk Management (iCRM) practice. He has experience in the domains of security governance, IT risk management, regulatory compliances, privacy, cyber security and cloud security. He is responsible for delivering governance, risk and compliance consulting and advisory services to Fortune 500 clients.
By Haris Hamidovic, Ph.D., CIA, ISMS IA
Fire protection best practices encompass all social actors (government bodies, other institutions, and all legal entities and citizens). Such inclusion is logical and necessary, considering the fact that a fire can occur in any area. As a result, all these social subjects are made responsible for fire protection, and fire protection must be an integral part of their regular activities. Each entity must also have an interest in protecting their personnel and property from a fire. Each entity must be aware of the causes of a fire, and secondly, each entity must be aware that it may be the cause of a fire.
Proper and consistent application of the technical norms and standards for design, installation, implementation, use and maintenance of electrical and other installations and devices is intended to prevent the outbreak of fire caused by these installations and devices. In many countries there is a legal obligation for correct and consistent application of appropriate fire protection measures provided for electrical and other installation, equipment and facilities.
The probability of fire originating in digital equipment (servers, storage units) is very low because there is little energy available to any fault and little combustible material within the equipment. But the associated risk may be significant considering IT equipment has become a vital and commonplace tool for business, industry, government and research groups. Numerous steps can be taken to avoid the risk of fire in the computer room environment. Compliance with the US National Fire Protection Association (NFPA) Standard for Fire Prevention NFPA 75 or British Standard 6266 will greatly increase the fire safety in computer rooms. These standards recommend minimum requirements for the protection of computer rooms from damage by fire and its associated effects.
Read Haris Hamidovic’s recent Journal article:
“Fire Protection of Computer Rooms—Legal Obligations and Best Practices,” ISACA Journal, volume 4, 2014.
|1 - 10