u COBIT i IT a ePoSure EXPOSURE Draft DRAFT - … for the CISA, CISM, CGEIT and CRISC certifications; the COBIT Foundation course; and ISMS and BCMS ... COBIT 5 Enablers for Securing

EXPOSUREDRAFT

Securing SenSitive PerSonal Data or information:

uSing COBIT® 5 for inDia’S IT act

Issued byISACA’s India Task Force

Based on:

EXPOSUREDRAFT

This document is currently out for exposure. We welcome your feedback and comments. You may provide them through the online survey found at

www.isaca.org/indiaSPDIcomments through 20 August 2012.

You may also contact Avinash Kadam directly at [email protected].

We also welcome your participation in our India discussion group which may be found in the ISACA Knowledge Center at

www.isaca.org/topic-India.

ISACA members and non-members may be a part of this group.

2

Securing SenSitive PerSonal Data or information: uSing coBit® 5 for inDia’S it act

EXPOSUREDRAFT

ISACA®

With more than 100,000 constituents in 180 countries, ISACA (www.isaca.org) is a leading global provider of knowledge, certifications, community, advocacy and education on information systems (IS) assurance and security, enterprise governance and management of IT, and IT-related risk and compliance. Founded in 1969, the nonprofit, independent ISACA hosts international conferences, publishes the ISACA® Journal, and develops international IS auditing and control standards, which help its constituents ensure trust in, and value from, information systems. It also advances and attests IT skills and knowledge through the globally respected Certified Information Systems Auditor® (CISA®), Certified Information Security Manager® (CISM®), Certified in the Governance of Enterprise IT® (CGEIT®) and Certified in Risk and Information Systems ControlTM (CRISCTM) designations.

ISACA continually updates and expands the practical guidance and product family based on the COBIT framework. COBIT helps IT professionals and enterprise leaders fulfill their IT governance and management responsibilities, particularly in the areas of assurance, security, risk and control, and deliver value to the business.

DisclaimerThis book is not intended to, and does not, provide legal, technical or other advice on compliance or related matters. Every entity or individual using this book should seek expert technical, legal or other advice as appropriate to its respective needs and circumstances. ISACA, its office bearers, its advisors/consultants, the authors, the reviewers and other persons associated with the writing, reviewing, printing or publication of this book do not guarantee or warrant the accuracy, adequacy, completeness or suitability of the content of this publication and they hereby disclaim any and all responsibility or liability for damages incurred as a result of the content contained herein. They also hereby disclaim any responsibility or liability whatsoever for the consequences of the use of this book by any person or entity. Courts in Cook County, state of Illinois, USA, alone shall have jurisdiction relating to any lawsuits pertaining to this book.

The opinions and views expressed in Securing Sensitive Personal Data or Information: Using COBIT 5 for India’s IT Act are solely those of the authors of this publication as a practical application and implementation of COBIT 5 principles and best practices. The opinions and views of the authors do not necessarily reflect those of ISACA.

Reservation of Rights© 2012 ISACA. All rights reserved. No part of this publication may be used, copied, reproduced, modified, distributed, displayed, stored in a retrieval system or transmitted in any form by any means (electronic, mechanical, photocopying, recording or otherwise) without the prior written authorisation of ISACA. Reproduction and use of all or portions of this publication are solely permitted for academic, internal and noncommercial use and for consulting/advisory engagements, and must include full attribution of the material’s source. No other right or permission is granted with respect to this work.

This text uses the following ISACA publications with permission:• ISACA, COBIT® 5.0, 2012. All rights reserved.• ISACA, COBIT® for Information Security, 2012. All rights reserved.

ISACA3701 Algonquin Road, Suite 1010Rolling Meadows, IL 60008 USAPhone: +1.847.253.1545Fax: +1.847.253.1443Email: [email protected] site: www.isaca.orgISACA® and COBIT® are registered trademarks of ISACA.

Participate in the ISACA Knowledge Center: www.isaca.org/topic-IndiaFollow ISACA on Twitter: https://twitter.com/ISACANewsJoin ISACA on LinkedIn: ISACA (Official), http://linkd.in/ISACAOfficial Like ISACA on Facebook: www.facebook.com/ISACAHQ

Securing Sensitive Personal Data or Information: Using COBIT 5 for India’s IT Act

3

EXPOSUREDRAFT

Acknowledgements

Acknowledgements

ISACA wishes to recognise:The ISACA India Growth Task ForceChairman, Mr. Niraj Kapasi, CISA, Kapasi Bangad Tech Consulting Pvt, Ltd. Hyderabad, IndiaMr. Sanjay Bahl, CISM, New Delhi, IndiaMr. Madhav C. Chablani, CISA, CISM, TippingEdge Consulting Pvt. Ltd, New Delhi, IndiaMr. Sandeep Narayan Godbole, CISA, CISM, CGEIT, Syntel, Pune, IndiaMr. Balakrishnan Natarajan, CISA, CISM, Target Corporation, Bangalore, IndiaMr. Vittal Raj, CISA, CISM, CGEIT, Kumar and Raj, Chennai, IndiaMr. Raghavendra Rao Hulgeri, CISA, Oracle Financial Services Software Ltd., Bangalore, IndiaMr. S V Sunder Krishnan, CISA, Reliance Life Insurance Company Limited, Mumbai, India

Additional Expert Reviewers:Abdul Rafeq, CISA, CGEIT, CIA, FCA, A Rafeq and Associates, Bangalore, IndiaMSV Rao, CISA, Hyderabad, IndiaBharat Mehta, VP, General Counsel and Ethics & Compliance Officer, Cap Gemini India, and Founder Member,

Technology Law Forum, Mumbai, IndiaMs. N S Nappinai, Advocate, High Court, Mumbai and Chennai, Founder Member, Technology Law Forum, India

4


EXPOSUREDRAFT

Authors

Avinash W. Kadam, CISA, CISM, CGEIT, CRISCAdvisor, ISACA’s India Task Force

Avinash Kadam is a leading authority on information security. He has four decades of experience in information technology management, information systems audit, information security consulting and training.

Kadam worked as head of information security, consulting and training of a leading organisation, MIEL e-Security Pvt. Ltd., for the past 11 years. Prior to this, he has worked in every role in information technology, beginning his career as a hardware engineer for mainframes, minis, personal computers and networks, and transitioning to head of computer operations, head of systems development and finally head of IT department of major organisations, where he was responsible for every aspect of IT, from strategy to implementation and day-to-day operations. This unique background taught him every angle of information security in an organisation: the people, processes and technology. All this experience is translated into effective training for students when he teaches.

Today Kadam is a well known and highly sought-after instructor/trainer for various information security courses such as preparation for the CISA, CISM, CGEIT and CRISC certifications; the COBIT Foundation course; and ISMS and BCMS implementation courses. He has the unique distinction of having conducted more than 100 CISSP CBK review seminars worldwide and has trained more than 1,500 information security professionals.

He frequently speaks at international conferences, among them ISACA’s Asia CACS, MEITSEC, World Conference on Disaster Management, Infosecurity and an event sponsored by The IIA. He also writes a regular column, “Technology and Risk,” in InformationWeek.

Kadam served as ISACA international vice president from 2006 to 2008. He was president of ISACA’s Mumbai Chapter from 1998 to 2000. He was the recipient of ISACA’s Harold Weiss Award in 2005, given to recognise dedication to the IS audit, control and security profession.

Mr. Subramaniam Vutha, B.Com, LL.M, ACS, DTMAdvocate

Subramaniam Vutha is the former senior vice president, legal, of Tata Infotech Ltd. and of Schoolnet India Limited. His areas of special interest include information technology law, intellectual property rights and e-commerce laws.

Vutha is a member of the International Technology Law Association, a worldwide body of technology lawyers. He is a former president and member of the board of Licensing Executives Society, India (LES). He is the first member of LES India to attend a train-the-trainer programme in Tokyo on intellectual asset management, conducted by LES International. He served as advisory board member of BNA International’s earlier publication titled World Internet Law Report.

Vutha acts as a lecturer on IT law at the University of Mumbai’s Department of Law, for LLM students. He is a former member of the working group on TRIPS, Confederation of Indian Industries, and the former co-chairman, WTO and Intellectual Property Rights Committee of the Bombay Chamber of Commerce and Industry. He was also a member of a legal advisory group constituted by the Controller of Certifying Authorities, Ministry of Information Technology, Government of India.

Vutha was a member of the in-house counsel panel constituted by the erstwhile World eBusiness Law Report, London, and is a founding member of the Technology Law Forum, a forum dedicated to building bridges between technology and the law.

5

EXPOSUREDRAFT

tAble of contents

tAble of contents

Preface........................................................................................................................................................................................6

Chapter 1. Indian Sensitive Personal Data or Information (SPDI) Protection Regulations ...........................................9

Chapter 2. How COBIT 5 Can Be Used to Secure SPDI ...................................................................................................18

Chapter 3. Meeting Stakeholders’ Needs for Securing SPDI ............................................................................................21

Chapter 4. COBIT 5 Enablers for Securing SPDI..............................................................................................................28Enabler 1: Principles, Policies and Frameworks.................................................................................................................29Enabler 2: Processes ............................................................................................................................................................41Enabler 3: Organisational Structures ..................................................................................................................................45Enabler 4: Culture, Ethics and Behaviour ..........................................................................................................................48Enabler 5: Information ........................................................................................................................................................50Enabler 6: Services, Infrastructure and Applications .........................................................................................................53Enabler 7: People, Skills and Competencies ......................................................................................................................54

Annexures ................................................................................................................................................................................56A. Glossary of Terms ...........................................................................................................................................................56B. List of Figures ..................................................................................................................................................................59C. List of Policies and Procedures .......................................................................................................................................60D. References .......................................................................................................................................................................61E. FAQs .................................................................................................................................................................................61

6


EXPOSUREDRAFT

PrefAce

Approach of This Publication

Sensitive personal data or information (SPDI) is used in every aspect of a business. It is used by very small organisations as well as very large enterprises. Securing SPDI cannot be done in isolation; the entire organisation has to be covered. Thus, the approach to securing SPDI should be holistic as well as customisable to suit the size and nature of the business of the organisation.

This publication is an effort to provide guidelines and best practices to the implementers who have the responsibility to secure SPDI for the entire enterprise. This has been done using the COBIT 5 framework. The book is organised in four sections:

Chapter 1. Indian Sensitive Personal Data or Information (SPDI) Protection RegulationsChapter 2. How COBIT 5 Can Be Used to Secure SPDIChapter 3. Meeting Stakeholders’ Needs for Securing SPDIChapter 4. COBIT 5 Enablers for Securing SPDI

Chapter 1. Indian Sensitive Personal Data or Information (SPDI) Protection Regulations

This chapter reproduces relevant provisions of the IT Act/Relevant Rules. To aid in understanding, the provisions of the IT Act/Relevant Rules have been set out in the form of bullets for ease of reading. In addition, key words have been underlined and words added (in brackets or parenthesis) for further clarification. Brief explanatory notes and checklists have also been included.

Chapter 2. How COBIT 5 Can Be Used to Secure SPDI

COBIT 5 is the latest edition of ISACA’s globally accepted framework, providing an end-to-end business view of the governance and management of enterprise IT that reflects the central role of information and technology in creating value for enterprises. The principles, practices, analytical tools and models found in COBIT 5 embody thought leadership and guidance from business, IT and governance experts around the world.

The executive summary of COBIT 5 is included as an introduction to this chapter. The two pages very succinctly explain the importance of information and how COBIT 5 and its five principles can help create a comprehensive framework helping organisations to achieve their objective of securing SPDI. After the executive summary, the question of how COBIT 5 can be used to secure SPDI is addressed.

Chapter 3. Meeting Stakeholders’ Needs for Securing SPDI

This chapter helps with identifying the stakeholders for SPDI and their specific needs for securing SPDI. The next step is identifying the enterprise goals that serve to meet the stakeholders’ needs.

Following the same process in a sequential manner, the IT-related goals, the enabler goals and the IT processes, which are part of enabler goal 2 and are necessary for securing SPDI, are identified, as illustrated below:

Stakeholders needs ° Enterprise goals ° IT-related goals ° Enabler goals

Chapter 4. COBIT 5 Enablers for Securing SPDI

This key chapter provides reasonable security practices and procedures for securing SPDI. The chapter begins with a one-page introduction to COBIT 5 enablers and is followed by detailed explanation of each enabler: • Enabler 1: Defines the principles, policies and frameworks of COBIT 5 and possible linkages to the IT ACT

requirements on SPDI• Enabler 2: Specifies the ten COBIT 5 processes for securing SPDI• Enabler 3: Determines the organisational structures and the roles and responsibilities related to securing SPDI• Enabler 4: Delineates the culture, ethics and behaviour that result in effectively securing SPDI• Enabler 5: Interprets the information’s quality by defining goals and adopting best practices for SPDI• Enabler 6: Describes the services, infrastructure and applications to secure SPDI• Enabler 7: Suggests the people, skills and competencies required for securing SPDI

Preface

7

EXPOSUREDRAFT

This book is presented in a two-column tabular format for clarity. The first column generally contains a question or a title/subtitle and the second column answers the question or provides further details pertinent to the title/subtitle. This format will help the reader to zero in on a specific topic.

The approach to the publication itself is summarised below.

1. What is the purpose of this book? This book focuses on helping you, the user, to secure (that is, to protect) sensitive personal data or information (hereinafter called SPDI or sensitive personal data) as required by India’s Information Technology Act, 20001 (as amended by the IT (Amendment) Act, 20082) and the Information Technology (Reasonable Security Practices and Procedures and Sensitive Personal Data or Information) Rules, 20113 (hereinafter called the IT Act).

The publication presents:• The ‘know-why’, that is to say, the reasons for securing sensitive personal data as required by India’s IT

Act, 2000, amended in 2008• The ‘know-how’ of securing SPDI, from the risk mitigation, operational and implementation angles

2. What does each chapter cover? The ‘know-why’ is explained in chapter 1. It explains relevant provisions of the IT Act and the relevant rules under the said Act.

The ‘know-how’ is provided in the following chapters:• Chapter 2 explains what COBIT 5 is and how it can be used to secure SPDI. • Chapter 3 identifies the stakeholders and their needs for securing SPDI.• Chapter 4 builds the seven enablers that will help to secure SPDI.

3. Who should read and use this book? All stakeholders, i.e., anyone who (or whose organisation) has a legal obligation under the IT Act and its Rules to secure sensitive personal data because they collect, process, transmit, transfer, store or deal with sensitive personal data. Such stakeholders could include owners of web sites, banks, insurance companies, financial institutions, hospitals, educational institutions, service providers, travel agents, payment gateway providers and social media platforms, among many other entities.

4. Why should you secure sensitive personal data?

You need to secure sensitive personal data because:• Amendments in 2008 to India’s IT Act of 2000 impose stringent obligations in this regard and stipulate

substantial compensation for breach of such obligations. • Contracts often impose stringent obligations and heavy penalties.• Certain sector-related laws, including those related to banking, require sensitive personal data protection.

5. Which aspects of such compliance does this book address?

• This book addresses compliance with India’s IT Act and the related Rules that: – Cover a wide range of business entities – Impose stringent and complex requirements relating to security of sensitive personal data – Stipulate substantial compensation for failing to comply• It does not address contractual obligations, because companies and businesses are usually aware of

their contractual obligations (having negotiated and accepted such contractual obligations).• It does not address sector-specific laws relating to sensitive personal data protection, because they

require the specific attention of the concerned entities alone, such as banks.

6. Why should you read this book? You should read and use this book to help you understand:• Whether you are covered by India’s IT Act’s provisions that require a wide range of entities that handle

sensitive personal data to fulfil various obligations• How to secure such sensitive personal data using a structured approach• How to document and demonstrate having done so• How to comply with the regulations to minimise the risk of having to pay heavy compensation for

noncompliance

7. How was this book conceived? This book was conceived by ISACA’s India Task Force to ensure that both the legal and information security aspects are covered in one book. The issue of securing sensitive personal data or information was addressed from the legal angle by a legal practitioner and from the information security angle by an information security expert. The aim is that every requirement of the IT Act relating to compliance with SPDI regulations can be adequately met by using the information security approaches suggested in this book.

The book is based on COBIT 5 principles. It adapts the business framework provided by COBIT 5 for the governance and management of IT to help meet the regulatory requirement of securing SPDI as per the IT Act.

1 The Information Technology Act, 2000, www.mit.gov.in/sites/upload_files/dit/files/downloads/itact2000/itbill2000.pdf2 The Information Technology (Amendment) Act, 2008, www.mit.gov.in/sites/upload_files/dit/files/downloads/itact2000/it_amendment_act2008.pdf3 Notifications from Ministry of IT, www.mit.gov.in/content/notifications

8


EXPOSUREDRAFT

8. How should you use this publication?

Use this publication as a handy ‘code of best practices’ guide for: • Meeting the requirements of the IT Act provisions on sensitive personal data protection• Understanding the specific actions you can take to check compliance with the IT Act provisions, in the

form of checklists• Clarifying the issues you need to understand, in the form of short notes• Identifying specific information security controls that are required and the requirements of the IT Act

that they meet• Understanding the enablers for implementation of measures to meet the requirements of the IT Act

Sensitive personal data or information has been referred to as SPDI. This term is defined specifically in the IT Act, as mentioned in item 3 of chapter 1 in this publication. In view of the specific nature of the definition in the IT Act, this term should not be confused with the widely used term ‘personal information’. A definition of the term ‘personal information’, as set out in the IT Act, is provided in the notes to item 3 of chapter 1. ‘Body corporate’, explained in chapter 1, is referred to as ‘enterprise’ or ‘organisation’ in later portions of this book.

9. What are the supporting publications?

The book follows the COBIT 5 approach. The relevant portions of COBIT 5 are reproduced in the book. However, the following ISACA publications provide details about the selected processes, available in COBIT 5: Enabling-Processes and COBIT 5 for Information Security. Implementation guidance is provided in COBIT 5 Implementation.• COBIT 54 • COBIT 5: Enabling Processes5

• COBIT 5 Implementation6

• COBIT 5 for Information Security7

Note: SPDI is a subset of the generic terms ‘data’ or ‘information’. In this publication, the terms ‘data’ or ‘information’ refer specifically to SPDI. Similarly, ‘risk’ means specifically SPDI risk.

4 COBIT 5, www.isaca.org/cobit5 COBIT 5: Enabling Processes, www.isaca.org/cobit/Documents/COBIT-5-Enabling-Processes-Introduction.pdf6 COBIT 5 Implementation, www.isaca.org/cobit/Documents/COBIT-5-Implementation-Introduction.pdf7 COBIT 5 for Information Security, www.isaca.org/COBIT/Pages/info-sec.aspx

Chapter 1. IndIan SenSItIve perSonal data or InformatIon (SpdI) proteCtIon regulatIonS

9

EXPOSUREDRAFT

chAPter 1IndIAn sensItIve PersonAl dAtA or InformAtIon (sPdI) ProtectIon regulAtIons

Objective

Securing SPDI is now mandated by India’s IT (Amendment) Act, 2008. This publication helps to provide an approach to achieve this objective using the COBIT 5 framework.

This chapter reproduces the text of relevant provisions of the IT Act and the relevant rules. To facilitate the understanding of the relevant provisions, the authors have set out the provisions in the form of bullets for ease of reading, underlined or otherwise highlighted key words, occasionally added some words (in brackets and parenthesis), and provided short notes and checklists. The checklists are referred to again in chapter 4, enabler 1, for defining various policies and procedures.

Step-by-step Explanation of the IT Act

The questions in the first column help focus attention on the purpose of a particular section.

1. How were specific privacy provisions added to the IT Act?

The IT Act provides for legal recognition for: • Electronic transactions• Electronic storage of information• Electronic filing of documents with government agencies

Specific provisions relating to personal data protection were added by amendment in 2008, which came into effect in 2009. Later, rules were issued; thus the IT Act and the Rules under the IT Act now specifically provide for personal data protection and physical privacy of sorts. This book addresses only sensitive personal data protection.

2. Who is obliged to protect sensitive personal data as per the IT Act and Rules? (See Section 43 A of the IT Act.) (See explanation (i) to Section 43 A of the IT Act.)

The obligation to protect sensitive personal data applies to every entity ( body corporate) that: • Possesses, deals with or handles any SPDI • In a computer resource that it owns, controls or operates

‘Body corporate’ means any company and includes:• A firm (such as a partnership firm)• Sole proprietorship (such as a consultancy firm owned by a single person)• Other association of individuals (such as professional bodies and organisations)

engaged in commercial or professional activities

Clarification by Government of India The Department of Information Technology of the Ministry of Communications & Information Technology, Government of India, issued a press release on 24 August 2011 stating, among other things:

These rules are regarding sensitive personal data or information and are applicable to the body corporate or any person located within India. Any such body corporate providing services relating to collection, storage, dealing or handling of sensitive personal data or information under contractual obligation with any legal entity located within or outside India is not subject to the requirement of Rules 5 & 6. Body corporate, providing services to the provider of information under a contractual obligation directly with them, as the case may be, however, is subject to Rules 5 & 6. Providers of information, as referred to in these Rules, are those natural persons who provide sensitive personal data or information to a body corporate.

Notes:• From the aforesaid press release it appears that Rule 5 (see item numbers 9 to 17 below, in this chapter)

and Rule 6 (see item numbers18 to 21 below, in this chapter) apply only to bodies corporate and persons located in India.

• Any such body corporate providing services relating to collection, storage, dealing or handling of sensitive personal data or information under contractual obligation with any legal entity located within or outside India is not subject to the requirements of Rules 5 and 6.

• But, if a body corporate provides services to a provider of SPDI under a contractual obligation directly with such provider of SDPI, such body corporate would be subject to Rules 5 and 6.

10


EXPOSUREDRAFT

2. Who is obliged to protect sensitive personal data as per the IT Act and Rules? (See Section 43 A of the IT Act.) (cont.) (See explanation (i) to Section 43 A of the IT Act.)

Checklist

1. Is the entity concerned a firm—sole proprietorship or partnership? A private limited or public limited company? Or any other association of individuals (such as those registered as a society or public trust or other organisation)?

2. Does it possess, deal with or handle sensitive personal data (explained below)?3. Are such data in a computer resource?4. Does the entity own, control or operate such computer resource?5. Is such firm, sole proprietorship or other association of individuals engaged in commercial or

professional activities?

3. What is sensitive personal data or information? (See Rule 3 of the Information Technology [Reasonable Security Practices and Procedures and Sensitive Personal Data or Information] Rules, 2011.)

SPDI has been defined under the Rules to mean such personal information that consists of information relating to: • Password• Financial information such as bank account, credit card, debit card or other payment instrument details• Physical, physiological and mental health condition• Sexual orientation• Medical records and history• Biometric information• Any detail relating to the above clauses as provided to the body corporate for providing service• Any of the information received under the above clauses by the body corporate for processing, stored or

processed under lawful contract or otherwise

Notes: The following definitions could be useful to consider:• Personal information (PI), which the I T Act defines as: ‘...any information that relates to a natural person,

which, either directly or indirectly, in combination with other information available or likely to be available with a body corporate, is capable of identifying such person’.

• Personally identifiable information (PII) (definition from National Institute of Standards and Technology [NIST] USA, SP800-122): ‘Any information about an individual maintained by an agency, including (1) any information that can be used to distinguish or trace an individual’s identity, such as name, social security number, date and place of birth, mother’s maiden name, or biometric records; and (2) any other information that is linked or linkable to an individual, such as medical, educational, financial, and employment information’.

Checklist

1. Do we have mechanisms in place to identify sensitive personal data already with us or provided to us for use, processing or storage?

2. Do we have in place mechanisms to determine if combinations of data available with us would apply to the aforesaid definition of sensitive personal data?

4 A. Is any public domain data or data under RTI or other law not covered? (See proviso to Rule 3 of the Information Technology [Reasonable Security Practices and Procedures and Sensitive Personal Data or Information] Rules, 2011.)

Any information that is freely available or accessible in public domain or furnished under the Right to Information Act, 2005, or any other law for the time being in force shall not be regarded as sensitive personal data or information for the purposes of these rules.

4 B. What does the RTI Act say about sensitive personal data or other confidential information?

Relevant portions of RTI Act, Sec 8.1., indicate that there shall be no obligation to give any citizen:• Information including commercially confidence, trade secrets or intellectual property, the disclosure of

which would harm the competitive position of a third party, unless the competent authority is satisfied that larger public interest warrants the disclosure of such information.

• Information available to a person in his fiduciary relationship, unless the competent authority is satisfied that the larger public interest warrants the disclosure of such information.

• Information that relates to personal information, the disclosure of which has no relationship to any public activity or interest, or that would cause unwarranted invasion of the privacy of the individual unless the Central Public Information Officer or the State Public Information Officer or the appellate authority, as the case may be, is satisfied that the larger public interest justifies the disclosure of such information.

• Provided that the information that cannot be denied to the Parliament or a State Legislature shall not be denied to any person.


11

EXPOSUREDRAFT

5. What happens if the body corporate fails to keep sensitive personal data secure? (See Section 43 A of the IT Act.)

Where an entity that is obliged to maintain security of sensitive personal data is negligent in implementing and maintaining reasonable security practices and procedures and thereby causes wrongful loss or wrongful gain to any person, such entity would be liable to pay damages by way of compensation to the person so affected. (See item 27 in this chapter on how compensation is decided.)

Checklist

1. Was the entity negligent in implementing and maintaining reasonable security practices and procedures (explained below)?

2. Was wrongful loss or wrongful gain caused to any person by such negligence?

6. What are the reasonable security practices to be implemented? (See Section 43 A of the IT Act.)

‘Reasonable security practices and procedures’* means security practices and procedures designed to protect information from unauthorised access, damage, use, modification, disclosure or impairment:• As may be specified in an agreement between the parties• As may be specified in any law for the time being in force• And in the absence of such agreement or any law, such reasonable security practices and procedures,

as may be prescribed by the Central Government in consultation with such professional bodies or associations as it may deem fit

(*See items 23 and 24 below for the relevant provisions of the Rules under the I T Act, that explain reasonable security practices and procedures.)

Checklist

1. Is it sensitive personal information? 2. Does any agreement specify protection from unauthorised access, etc.?3. Does any sector-specific law specify such protection?4. Is protection specified under the Central Government notified Rules issued on 11 April 2011 and titled

‘Information Technology (Reasonable Security Practices and Procedures and Sensitive Personal Data or Information) Rules, 2011?

7. What are a body corporate’s obligations as to privacy policy? (See Rule 4 of the Information Technology [Reasonable Security Practices and Procedures and Sensitive Personal Data or Information] Rules, 2011.)

Rule 4. Body corporate to provide policy for privacy and disclosure of information. (1) The body corporate or any person who on behalf of body corporate collects, receives, possesses, stores, deals or handles information of provider of information, shall provide a privacy policy for handling of or dealing in personal information including sensitive personal data or information and ensure that the same are available for view by such providers of information who have provided such information under lawful contract.

The Department of Information Technology of the Ministry of Communications & Information Technology, Government of India, issued a press release on 24 August 2011 stating, among other things:

‘It is also clarified that privacy policy, as prescribed in Rule 4, relates to the body corporate and is not with respect to any particular obligation under any contract’.

Note: The purport of this clarification appears to be that any contractual obligations assumed by a body corporate would not necessarily be covered by the privacy policy prescribed under Rule 4.

Checklist

1. Do we collect, receive, possess, store, deal with or handle personal information ( including sensitive personal data)?

2. Is the personal information made available under lawful contract? 3. Do we have a privacy policy?4. Is the personal information available for viewing by the people who provide their personal information?

8. Where should the privacy policy be posted? What should it cover? (See Rule 4 of the Information Technology [Reasonable Security Practices and Procedures and Sensitive Personal Data or Information] Rules, 2011.)

Such policy shall be published on the web site of the body corporate or any person on its behalf and shall provide for:• Clear and easily accessible statements of its practices and policies • Type of personal or sensitive personal data or information collected under Rule 3 • Purpose of collection and usage of such information• Disclosure of information including sensitive personal data or information as provided in Rule 6 • Reasonable security practices and procedures as provided under Rule 8

Note: A procedure usually describes how we will fulfil the intent or commitment stated in our policy.

Caution: • Because sensitive personal information is often transmitted across borders, it is important to consider all

the relevant regulations that may apply. Sometimes those of more than one country may apply.• While aiming at compliance with India’s IT Act and the Rules under that Act, adapting a prescribed

standard appropriately may be necessary, to ensure comprehensive compliance.

12


EXPOSUREDRAFT

8. Where should the privacy policy be posted? What should it cover? (cont.) (See Rule 4 of the Information Technology [Reasonable Security Practices and Procedures and Sensitive Personal Data or Information] Rules, 2011.)

Checklist

1. Is our privacy policy clear? Have we obtained feedback after review by persons who have provided their personal information?

2. Does it cover both our policies and practices? • A policy is an overall intention and direction as formally expressed by management. • A good practice is a proven activity or process that has been successfully used by multiple enterprises

and has been shown to produce reliable results.3. Does it explain the type of personal information that we collect?4. Does it explain why we collect and use the personal data (the purpose)?5. Is the purpose stated by us broad enough to cover potential uses of the personal information that

we can foresee?6. Do we state how and to whom we may disclose the personal data? 7. Is such statement of possible disclosure broad enough to cover potential disclosures that we can foresee?8. Does the policy state how we adopt the ‘reasonable security practices and procedures’, as explained below?

9. How do we get consent for collection or usage of personal data? (See Rule 5 of the Information Technology [Reasonable Security Practices and Procedures and Sensitive Personal Data Information] Rules, 2011.)

The body corporate or any person on its behalf shall obtain:• Consent in writing through letter or fax or consent given by any mode of electronic communication* • From the provider of the sensitive personal data• Regarding purpose of usage• Before collection of such information

* The Department of Information Technology of the Ministry of Communications & Information Technology, Government of India, issued a press release on 24 August 2011 stating, among other things:

‘Further, in Rule 5(1) consent includes consent given by any mode of electronic communication’.

Note: Hence, web-based consent or mobile-message-based consent could qualify as valid consent.

Checklist

1. Have we obtained consent from the provider of personal data?2. Was the consent in writing (including any mode of electronic communication)? 3. Did we get consent before we collected the data?4. Did the consent cover the proposed usage of the data?5. Will such consent be retrievable when needed?

10. What is ‘lawful purpose’ for collection of sensitive personal data? (See Rule 5 [2] [a] of the Information Technology [Reasonable Security Practices and Procedures and Sensitive Personal Data or Information] Rules, 2011.)

A lawful purpose is:• Connected with a function or activity of the body corporate or any person on its behalf• One for which the collection of the sensitive personal data or information is considered necessary

for that purpose

Checklist

1. Have we defined the purpose for collection of sensitive personal data?2. Is such purpose connected with one or more of our functions or activities? 3. Are the data collected necessary for such function or activity? 4. Who (in the organisation) considered it necessary? Is the reasoning for such consideration duly documented?

11. How do we collect sensitive personal data? (See Rule 5 [3] of the Information Technology [Reasonable Security Practices and Procedures and Sensitive Personal Data or Information] Rules, 2011.)

While collecting information directly from the person concerned, the body corporate or any person on its behalf shall take such steps as are, in the circumstances, reasonable to ensure that the person concerned is having the knowledge of:• The fact that the information is being collected• The purpose for which the information is being collected• The intended recipients of the information• The name and address of: – The agency that is collecting the information – The agency that will retain the information

Checklist

1. Have we disclosed that we are collecting the data?2. Have we disclosed the purpose for such collection? Is the purpose stated broad enough to cover potential

future uses of the data? 3. Have we indicated who will be the recipients of the data? Is such indication broad enough to cover all

contemplated future recipients?4. Have we indicated the full name and address of the agency collecting the data and of the agency that will

retain the information?5. Most importantly, have the appropriate management personnel determined the steps that are needed

to ensure the aforesaid and whether such steps are reasonable in the circumstances? Have they documented their reasons for considering these steps reasonable and adequate?


13

EXPOSUREDRAFT

12. How do we address retention/use? (See Rule 5 [4] of the Information Technology [Reasonable Security Practices and Procedures and Sensitive Personal Data or Information] Rules, 2011.)

The body corporate or any person on its behalf holding sensitive personal data or information shall not retain that information for longer than is required for the purposes for which the information may lawfully be used or is otherwise required under any other law for the time being in force.

The information collected shall be used for the purpose for which it has been collected.

Checklist

1. Do we have a retention policy for sensitive personal data?2. Does that policy indicate how long we will retain such data or different types of such data?3. Do we have a mechanism to determine whether such retention periods are no longer than is required for

the purposes for which the information may lawfully be used or is otherwise required under any other law that may apply? Who (in the organisation) decides this and how? Are the reasons for such retention periods documented?

4. Do we have mechanisms to ensure retention per such policy?5. Do we have mechanisms for checking if the data are used only for the stated purposes?6. Are these mechanisms tested and reviewed?

13. What are the personal information provider’s rights to review accuracy, etc., of his/her information with the body corporate? (See Rule 5 [6] of the Information Technology [Reasonable Security Practices and Procedures and Sensitive Personal Data or Information] Rules, 2011.)

The body corporate or any person on its behalf shall:• Permit the providers of information to review the information they have provided as and when requested

by them• Ensure that any personal information or sensitive personal data or information found to be inaccurate or

deficient is corrected or amended as feasible

Note: The right to review extends not just to sensitive personal information but to all personal information provided. The provider can also seek corrections or amendments to address any inaccuracies or deficiencies, which could include, for example, spelling errors, wrong addresses and incomplete details.

Checklist

1. Do we have a mechanism for personal information providers to seek review at any time of the information they have provided?

2. Does such mechanism provide ways in which to verify if the information is inaccurate or deficient (e.g., the information is different from that provided by the information provider or the information is not complete)?

3. Do we have a mechanism to organise corrections or amendments?

14. No authenticity obligation for body corporate (See proviso to Rule 5 [6] of the Information Technology [Reasonable Security Practices and Procedures and Sensitive Personal Data or Information] Rules, 2011.)

The body corporate is not responsible for the authenticity of the personal information or sensitive personal data or information supplied by the provider of information to such body corporate or any other person acting on behalf of such body corporate.

Note: While the body corporate need not validate the data collected, it is still responsible for the ‘integrity’ of the data as supplied and collected. That is to say, the information provided must not be altered or tampered with, but its veracity need not be ascertained. If, however, the information appears false or incomplete on the face of it, the body corporate should enquire into the matter before accepting the information.

15. Opt-out option for SPDI provider (See Rule 5 [7] of the Information Technology [Reasonable Security Practices and Procedures and Sensitive Personal Data or Information] Rules, 2011.)

The body corporate or any person on its behalf shall:• Prior to the collection of information, including SPDI, provide an option to the provider of the information

to not provide the data or information sought to be collected. • Give the provider of information, at any time, while availing of the services of the body corporate or

otherwise, an option to withdraw consent given earlier to the body corporate.

Notes:• Withdrawal of the consent shall be sent in writing to the body corporate. (In terms of the IT Act, writing can

include electronic communication.) • If the consent is not given or is withdrawn, the body corporate shall have the option to refrain from

providing the goods or services for which the said information was sought.

Checklist

1. Do we give the provider of personal data an option to not provide the data?2. Do we give this option before collecting the data?3. Do we give the provider of data an option of withdrawing consent for collection or use of the data? 4. Is the option for withdrawal of consent available at any time?

14


EXPOSUREDRAFT

16. The body corporate or any person on its behalf shall keep the information secure. (See Rule 5 [8] of the Information Technology [Reasonable Security Practices and Procedures and Sensitive Personal Data or Information] Rules, 2011. Also Section 72 A of the IT Act.)

Checklist

1. Have we read and understood Rule 8 (see below) as it applies to our organisation? Consider items 23 and 24 below.

2. Have we read and understood the implications of Section 72 A of the IT Act? See item 28 below

17. Grievance officer and mechanism (See Rule 5 [9] of the Information Technology [Reasonable Security Practices and Procedures and Sensitive Personal Data or Information] Rules, 2011.)

The body corporate shall address any discrepancies and grievances of the provider of the information with respect to processing of information in a time-bound manner. For this purpose, the body corporate shall designate a grievance officer and publish his/her name and contact details on its web site. The grievance officer shall redress the grievances of provider of information expeditiously but (in any event) within one month from the date of receipt of grievance.

Checklist

1. Have we designated a grievance officer to address any discrepancies and grievances of the provider of the data with respect to processing of data?

2. Do we have a mechanism for addressing these in a time-bound manner?3. Is such time limit specified? Is it less than one month? Is the time limit adhered to? 4. Are the name, contact and other details of the grievance officer displayed conspicuously on our web site?

Are these details made known to all employees?

18. Non-disclosure duties (See Rule 6 [1] of the Information Technology [Reasonable Security Practices and Procedures and Sensitive Personal Data or Information] Rules, 2011.)

Disclosure of sensitive personal data or information by the body corporate to any third party shall require prior permission from the provider of such information, who has provided such information under lawful contract or otherwise, unless such disclosure has been agreed to in the contract between the body corporate and provider of information, or where the disclosure is necessary for compliance of a legal obligation.

Checklist

1. Do we disclose sensitive personal data to third parties? 2. Are such third parties identified and listed?3. Do we have the prior permission of the providers of the sensitive personal information for such disclosure? 4. Or, is there a contract with the provider of the sensitive personal information that allows such disclosure? 5. Or, is such disclosure necessary for compliance with a legal obligation? 6. Is there a mechanism to review requests for disclosure of sensitive personal information in compliance

with a legal obligation (e.g., in ‘returns’ or forms filed with the state or central government)?

19. No restriction on transfer to a mandated government agency (See proviso to Rule 6 [1] of the Information Technology [Reasonable Security Practices and Procedures and Sensitive Personal Data or Information] Rules, 2011.)

• SPDI shall be shared, without obtaining prior consent from provider of information, with government agencies mandated under the law to obtain information including SPDI for the purpose of verification of identity, or for prevention, detection, and investigation, including cyber incidents, prosecution, and punishment of offences. The government agency shall send a request in writing to the body corporate possessing the SPDI stating clearly the purpose of seeking such information. The government agency shall also state that the information so obtained shall not be published or shared with any other person.

• Notwithstanding anything contained in sub-Rule (1), any SPDI shall be disclosed to any third party by an order under the law for the time being in force.

Notes: • The purposes for which a government agency can request sensitive personal data are: – Verification of identity – Prevention, detection, and investigation, including cyber incidents, prosecution, and punishment of offences• If an order under any law so requires, sensitive personal data must be shared in compliance with such order.

Checklist

1. Do we have a mechanism in place to address requests for sensitive personal information from government agencies?

2. Are the people handling such matters trained to: • Identify such requests? • Determine if the concerned government agency is mandated by the law to seek such data? • Determine if the purpose of the request is clear and as per the law (see note below)? • Determine if the agency has stated specifically that such shared data will not be published or shared

with any other person?

20. Duty not to publish (See Rule 6 [3] of the Information Technology [Reasonable Security Practices and Procedures and Sensitive Personal Data or Information] Rules, 2011.)

The body corporate or any person on its behalf shall not publish the SPDI.

Checklist

1. Do we have mechanisms in place to: • Review all materials published by us? • Check if any sensitive personal data are part of such materials? • Mask or redact such sensitive personal data?


15

EXPOSUREDRAFT

21. No further disclosure by the third party (See Rule 6 [4] of the Information Technology [Reasonable Security Practices and Procedures and Sensitive Personal Data or Information] Rules, 2011.)

The third party* receiving the SPDI from the body corporate or any person on its behalf under sub-Rule (1) shall not disclose it further.

*The term ‘third party’ is the entity referred to in item 18 above. The third party could be a client, vendor, partner or other affiliate of the body corporate.

Note: Publication ordinarily means making available to the public or a significant part of the public. Merriam Webster defines it as (a) to make generally known, (b) to make public announcement of; to disseminate to the public, (c) to produce or release for distribution.

Checklist

1. Do we obtain agreement from third parties with whom we share sensitive personal data to refrain from further disclosing such data?

2. Do we have a mechanism in place to ensure the above?

22. Transfer of information (See Rule 7 of the Information Technology [Reasonable Security Practices and Procedures and Sensitive Personal Data or Information] Rules, 2011.)

A body corporate or any person on its behalf may transfer SPDI, including any information, to any other body corporate or a person in India or located in any other country, that ensures the same level of data protection that is adhered to by the body corporate as provided for under these Rules. The transfer may be allowed only if it is necessary for the performance of the lawful contract between the body corporate or any person on its behalf and the provider of information, or where such person has consented to data transfer.

Checklist

1. Do we transfer sensitive personal data to any other body corporate or person in India or abroad?2. Do we have a mechanism in place to check if the proposed transferee ensures the same level of data

protection as required under the Indian rules?3. Do we have a mechanism in place to check if such transfers are made only: • For the performance of lawful contracts between us and the provider of the information? • Or, where the provider of information has consented to such transfer?

23. Compliance with requirements of reasonable security practices and procedures (See Rule 8 [1] of the Information Technology [Reasonable Security Practices and Procedures and Sensitive Personal Data or Information] Rules, 2011.)

A body corporate or a person on its behalf shall be considered to have complied with reasonable security practices and procedures, if they have implemented such security practices and standards and have a comprehensive documented information security programme and information security policies that contain managerial, technical, operational and physical security control measures that are commensurate with the information assets being protected with the nature of business. In the event of an information security breach, the body corporate or a person on its behalf shall be required to demonstrate, as and when called upon to do so by the agency mandated under the law, that they have implemented security control measures as per their documented information security programme and information security policies.

Checklist

1. Do we have in place appropriate information security policies?2. Do such policies contain managerial, technical, operational and physical security control measures? 3. Are such measures commensurate with the information assets being protected and the nature of

our business?4. Do we have in place a comprehensive information security programme?5. Is the information security programme well documented?6. Do we consistently implement such security practices and standards?7. Can we demonstrate, whenever called upon to do so by an agency mandated under the law, that we have

implemented security control measures as per our documented information security programme and policies? (Such requests can be anticipated whenever there is an information security breach.)

24. Options of government-approved standards (See Rules 8 [2] and 8 [3] of the Information Technology [Reasonable Security Practices and Procedures and Sensitive Personal Data or Information] Rules, 2011.)

The international standard ISO/IEC 27001:2005, Information technology—Security techniques—Information security management systems—Requirements8 is one such standard referred to in sub-Rule (1).

Any industry association or an entity formed by such an association, whose members are self-regulating by following other than ISO/IEC codes of best practices for data protection as per sub-Rule(1), shall get its codes of best practices duly approved and notified by the Central Government for effective implementation.

Checklist

1. Have we adopted and implemented the international standard ISO/IEC 27001:2005, Information technology—Security techniques—Information security management systems—Requirements (Note: Annexure A.15 of ISO/IEC 27001:2005 deals with compliance with legal requirements. Item A.15.1.1.of the said annexure requires ‘Identification of applicable legislation’. The control for this requires the following: ‘All relevant statutory, regulatory and contractual requirements and the organisation’s approach to meet these requirements shall be explicitly defined, documented, and kept up-to-date for each information system and the organisation’.)

2. Are we certified as having done so?3. Is our certification valid and current?4. Are any alternative standards as permitted under the IT Act and Rule 8 (2) available? 5. Have we evaluated such alternative standards?

8 ISO/IEC 27001:2005, Information technology—Security techniques—Information security management systems—Requirements

16


EXPOSUREDRAFT

25. Audit requirements (See Rules 8 [4] of the Information Technology [Reasonable Security Practices and Procedures and Sensitive Personal Data or Information] Rules, 2011.)

The body corporate or a person on its behalf who has implemented either ISO/IEC 27001:2005 or the codes of best practices for data protection as approved and notified under sub-Rule (3) shall be deemed to have complied with reasonable security practices and procedures provided that such standard or the codes of best practices have been certified or audited on a regular basis by entities through an independent auditor, duly approved by the Central Government. The audit of reasonable security practices and procedures shall be carried out by an auditor at least once a year or as and when the body corporate or a person on its behalf undertakes significant upgradation of its processes and computer resources.

Note:• An audit of security practices and procedures must be carried out at least once a year. • It must also be carried out when the entity undertakes significant upgradation of its processes and

computer resources. (The terms ‘significant’ and ‘upgradation’ have not been defined but the authors recommend that an independent opinion be sought whenever needed on this aspect.)

• The audit is to be conducted by an approved auditor only.

Checklist

1. Have we implemented ISO/IEC 27001:2005 or another code of best practices for data protection as approved and notified by the Central Government of India?

2. Have we been certified and/or audited on a regular basis (see note below) as having implemented data protection as described above?

3. Has such certification or audit been conducted by an independent auditor duly approved by the Central Government of India? (The qualifications and credentials of those auditors are yet to be notified.)

26. Who will determine default? (See Section 46 of the IT Act.)

• For adjudging contraventions of the provisions under Section 43 A or a related rule or regulation and to determine the penalty/compensation, the Central Government shall appoint an officer not below Director Government of India or an equivalent officer of a State Government as adjudicating officer.

• The enquiry will be conducted as prescribed by the Central Government.• The adjudicating officer shall exercise jurisdiction in matters in which the claim for injury or damage does

not exceed rupees five crore (rupees fifty million). [For such actions, i.e., actions that may be initiated before an adjudicating officer, a civil court cannot exercise jurisdiction. ]

• Beyond the aforesaid threshold, the jurisdiction to determine compensation shall vest with the competent court.

• The adjudicating officer must possess such experience in the field of information technology and legal or judicial experience as may be prescribed by the Central Government.

27. How will compensation be decided? (See Section 47 of the IT Act.)

While adjudging the quantum of compensation, the adjudicating officer shall have due regard to the following factors:• The amount of gain of unfair advantage, wherever quantifiable, made as a result of the default• The amount of loss caused to any person as a result of the default• The repetitive nature of the default

28. IT Act provision for providing punishment for disclosure of information in breach of lawful contract (See Section 72A of the IT Act, inserted in 2008.)

Punishment for disclosure of information in breach of lawful contract: Save as otherwise provided in this Act or any other law for the time being in force, any person including an intermediary who, while providing services under the terms of lawful contract, has secured access to any material containing personal information about another person, with the intent to cause or knowing that he is likely to cause wrongful loss or wrongful gain discloses, without the consent of the person concerned, or in breach of a lawful contract, such material to any other person, shall be punished with imprisonment for a term which may extend to three years, or with fine which may extend to five lakh rupees (rupees 0.5 million) or with both.

29. Could there be remedies outside the IT Act? (See Section 77 of the IT Act.)

Nonexclusive remedies:‘No compensation awarded, penalty imposed or confiscation made under this Act shall prevent the award of compensation or imposition of any other penalty or punishment under any other law for the time being in force’.


17

EXPOSUREDRAFT

30. India’s personal data protection requirements (other than those under the IT Act)

These are described under the following three headings:• Under the law of contracts• Personal data protection under sector-specific laws• Privacy rights read into certain fundamental rights

1. Under the law of contracts For the sake of completeness this section deals with certain legal provisions for protection of personal data, other than those in the IT Act. (The word ‘data’ is used to include both data and information, any distinction between these terms being not relevant to this publication.)• Contractual obligations of personal data protection

Contracts with vendors, clients, partners, employees and the like often include specific provisions for protection of personal data. These obligations may be based upon legal obligations under a law in force for that purpose or they may be in accordance with the relevant party’s privacy practices, policies or procedures. How are these provisions enforced? According to the Indian Contract Act, when a party commits a breach of contract, the aggrieved party is entitled to receive compensation for any loss or damage caused to it or, in certain cases, to a court order for ‘specific performance’ of the contract against the party in default.

2. Personal data protection under sector-specific lawsThe Credit Information Companies (Regulation) Act, 2005, refers to certain privacy principles. Section 19 of that Act reads as follows: Accuracy and security of credit information. A credit information company or credit institution or specified user, as the case may be, in possession or control of credit information, shall take such steps (including security safeguards) as may be prescribed, to ensure that the data relating to the credit information maintained by them is accurate, complete, duly protected against any loss or unauthorised access or use or unauthorised disclosure thereof.

The Public Financial Institutions [Obligations as to Fidelity and Secrecy] Act of 1983—This Act provides for confidentiality in bank transactions. For example, banks are obliged to keep in confidence details of its customer’s transaction in the books of the bank, to protect the customer’s interests and reputation.

3. Privacy rights read into certain fundamental rightsIn various matters before it, the Honorable Supreme Court of India has passed orders reading privacy rights into certain fundamental rights; but such rights are subject to some permitted restrictions. However, these orders generally relate only to actions of the government.

Conclusion

This chapter has provided the requisite ‘know-why’, that is to say, the reasons for securing sensitive personal data as required by India’s IT Act, 2000, amended in 2008, and Rules for SPDI under the said Act.

The next chapter creates the background by first giving an executive summary of COBIT 5 to familiarise readers with the relevant concepts and then explaining how COBIT 5 can be used to secure SPDI.

18


EXPOSUREDRAFT

chAPter 2how cobIt 5 cAn be used to secure sPdIExecutive Summary of COBIT 5

Information is a key resource for all enterprises, and from the time that information is created to the moment that it is destroyed, technology plays a significant role. Information technology is increasingly advanced and has become pervasive in enterprises and in social, public and business environments.

As a result, today, more than ever, enterprises and their executives strive to:• Maintain high-quality information to support business decisions.• Generate business value from IT-enabled investments, i.e., achieve strategic goals and realise business benefits through

effective and innovative use of IT.• Achieve operational excellence through the reliable and efficient application of technology.• Maintain IT-related risk at an acceptable level.• Optimise the cost of IT services and technology.• Comply with ever-increasing relevant laws, regulations, contractual agreements and policies.

Over the past decade, the term ‘governance’ has moved to the forefront of business thinking in response to examples demonstrating the importance of good governance and, on the other end of the scale, global business mishaps.

Successful enterprises have recognised that the board and executives need to embrace IT like any other significant part of doing business. Boards and management—both in the business and IT functions—must collaborate and work together, so that IT is included within the governance and management approach. In addition, legislation is increasingly being passed and regulations implemented to address this need.

COBIT 5 provides a comprehensive framework that assists enterprises in achieving their objectives for the governance and management of enterprise IT. Simply stated, it helps enterprises create optimal value from IT by maintaining a balance between realising benefits and optimising risk levels and resource use. COBIT 5 enables IT to be governed and managed in a holistic manner for the entire enterprise, taking in the full end-to-end business and IT functional areas of responsibility, considering the IT-related interests of internal and external stakeholders. COBIT 5 is generic and useful for enterprises of all sizes, whether commercial, not-for-profit or in the public sector.

Figure 1—COBIT 5 Principles

1. MeetingStakeholder

Needs

5. SeparatingGovernance

FromManagement

4. Enabling aHolistic

Approach

3. Applying aSingle

IntegratedFramework

2. Covering theEnterpriseEnd-to-end

COBIT 5Principles

Chapter 2 how CoBIt 5 Can Be Used to seCUre spdI

19

EXPOSUREDRAFT

COBIT 5 is based on five key principles (shown in figure 1) for governance and management of enterprise IT:• Principle 1: Meeting Stakeholder Needs—Enterprises exist to create value for their stakeholders by maintaining a

balance between the realisation of benefits and the optimisation of risk and use of resources. COBIT 5 provides all of the required processes and other enablers to support business value creation through the use of IT. Because every enterprise has different objectives, an enterprise can customise COBIT 5 to suit its own context through the goals cascade, translating high-level enterprise goals into manageable, specific, IT-related goals and mapping these to specific processes and practices.

• Principle 2: Covering the Enterprise End-to-end—COBIT 5 integrates governance of enterprise IT into enterprise governance:

– It covers all functions and processes within the enterprise; COBIT 5 does not focus only on the ‘IT function’, but treats information and related technologies as assets that need to be dealt with just like any other asset by everyone in the enterprise.

– It considers all IT-related governance and management enablers to be enterprisewide and end-to-end, i.e., inclusive of everything and everyone—internal and external—that is relevant to governance and management of enterprise information and related IT.

• Principle 3: Applying a Single, Integrated Framework—There are many IT-related standards and best practices, each providing guidance on a subset of IT activities. COBIT 5 aligns with other relevant standards and frameworks at a high level, and thus can serve as the overarching framework for governance and management of enterprise IT.

• Principle 4: Enabling a Holistic Approach—Efficient and effective governance and management of enterprise IT require a holistic approach, taking into account several interacting components. COBIT 5 defines a set of enablers to support the implementation of a comprehensive governance and management system for enterprise IT. Enablers are broadly defined as anything that can help to achieve the objectives of the enterprise. The COBIT 5 framework describes seven categories of enablers:

– Principles, Policies and Frameworks – Processes – Organisational Structures – Culture, Ethics and Behaviour – Information – Services, Infrastructure and Applications – People, Skills and Competencies • Principle 5: Separating Governance From Management—The COBIT 5 framework makes a clear distinction

between governance and management. These two disciplines encompass different types of activities, require different organisational structures and serve different purposes. COBIT 5’s view on this key distinction between governance and management is:

– Governance

Governance ensures that stakeholder needs, conditions and options are evaluated to determine balanced, agreed-on enterprise objectives to be achieved; setting direction through prioritisation and decision making; and monitoring performance and compliance against agreed-on direction and objectives.

In most enterprises, overall governance is the responsibility of the board of directors under the leadership of the chairperson. Specific governance responsibilities may be delegated to special organisational structures at an appropriate level, particularly in larger, complex enterprises.

– Management

Management plans, builds, runs and monitors activities in alignment with the direction set by the governance body to achieve the enterprise objectives. In most enterprises, management is the responsibility of the executive management under the leadership of the chief executive officer (CEO).

Together, these five principles enable the enterprise to build an effective governance and management framework that optimises information and technology investment and use for the benefit of stakeholders.

20


EXPOSUREDRAFT

How COBIT 5 Can Be Used for Securing SPDI

The executive summary of COBIT 5 succinctly explains the importance of information and how COBIT 5 and its five principles and seven enablers can create a comprehensive framework, helping organisations to achieve their objectives.

The next step is to understand how COBIT 5 can be used to secure SPDI. The explanation below creates the link between the COBIT 5 framework and how it is used for securing SPDI.

How can COBIT 5 be used to secure SPDI?

COBIT 5 is a comprehensive governance and management framework with the following valuable features:• A holistic approach• Ability to be customised to meet stakeholders’ specific needs

Securing SPDI is a specific requirement as per the IT Act and related Rules. Because SPDI today is used in every aspect of a business, securing it cannot be done in isolation. Only a holistic approach, as provided by COBIT 5, can assure that SPDI has truly been secured across the enterprise.

SPDI is used by very small organisations, e.g., a small pathology laboratory, as well as very large enterprises, e.g., a multinational enterprise having extensive e-commerce activities. The approach to secure SPDI should be customisable. COBIT 5 provides this flexibility.

COBIT 5 helps to identify the following:• Stakeholders’ needs for securing SPDI, which are the issues to be addressed through application of COBIT 5 • Enterprise goals to meet the identified stakeholders’ needs• IT-related goals that will meet the challenges of the enterprise goals• Enablers that will help to meet the challenges of achieving the IT-related goals

The goals cascade is summarised below:


Enablers are factors that, individually and collectively, influence whether something will work. The seven enablers of COBIT 5 will help in achieving the objective of securing SPDI. Enablers are driven by the goals cascade, i.e., higher-level IT-related goals define what the different enablers should achieve.• Enabler 1: Principles, Policies and Framework. The approach to secure SPDI is broadly based on the

Organisation for Economic Co-operation and Development (OECD) principles of ‘fair information practices’. Based on these principles and also on the requirements of IT Act, the ‘privacy policy for SPDI’, ‘SPDI security policies’ and various supporting procedures are formulated. A sound privacy framework becomes the cornerstone of securing SPDI.

• Enabler 2: Processes. The IT processes themselves are derived from the stakeholders’ needs. The selected processes support defining various procedures and activities, which can then be implemented for any organisation of any size, ranging from a small setup to a very large enterprise.

• Enabler 3: Organisational Structures. A well-formulated organisational structure with clearly defined roles and responsibilities is necessary for securing SPDI.

• Enabler 4: Culture, Ethics and Behaviour. This is as necessary for securing SPDI as are the policies and procedures. An organisation has to strongly believe in the need for doing something right and only then it will be done.

• Enabler 5: Information. SPDI is a special subset of the generic terms ‘data’ or ‘information’. Because of SPDI’s sensitive nature, it has many stringent goals for quality and security and these must be built into the various procedures for privacy and security.

• Enabler 6: Services, Infrastructure and Applications. This enabler helps to create the service capabilities to meet the requirements of securing the SPDI.

• Enabler 7: People, Skills and Competencies. Securing SPDI is a relatively new concept in India. It will require sustained effort by organisations to internalise it and make it an integral part of the business practice. This can be done by identifying and providing skills and competencies at each level in the organisation.

COBIT 5 clearly differentiates between governance and management activities and assigns roles and responsibilities accordingly. Implementation of clearly defined metrics as defined in COBIT 5 facilitates in measuring and controlling each process.

Conclusion

This chapter explained the COBIT 5 principles and how COBIT 5 can be used to secure SPDI.

Chapter 3 Meeting StakeholderS’ needS for SeCuring Spdi

21

EXPOSUREDRAFT

chAPter 3meetIng stAkeholders’ needs for securIng sPdIThis chapter helps first to identify the stakeholders of SPDI and their specific needs for securing the SPDI. The next step is to identify the enterprise goals that serve to meet the stakeholders’ needs. Following the same process in a sequential manner, the IT-related goals and then enabler goals, which also include IT processes necessary for securing the SPDI, are identified.

Figure 2 contains an overview of the COBIT 5 goals cascade. Stakeholders’ needs can be related to a set of generic enterprise goals. These enterprise goals have been developed using the balanced scorecard (BSC) dimensions, and they represent a list of commonly used goals that enterprises define for themselves. Although this list is not exhaustive, most enterprise-specific goals can be mapped easily onto one or more of the generic enterprise goals. (Refer to COBIT 5, figure 5, for COBIT 5 enterprise goals.)

Figure 2—COBIT 5 Goals Cascade Overview

BenefitsRealisation

Stakeholder Drivers(Environment, Technology Evolution, …)

Enterprise Goals

IT-related Goals

Enabler Goals

Influence

Cascade to

Cascade to

ResourceOptimisation

RiskOptimisation

Stakeholder Needs

Cascade to

22


EXPOSUREDRAFT

Who are the stakeholders for securing SPDI?

For securing SPDI, a stakeholder is anyone who (or whose organisation) has a legal obligation under the IT Act and its Rules to:• Secure sensitive personal data• Because such person or entity collects, processes, transmits, transfers, stores or deals with sensitive

personal data

Accountability for securing SPDI is with the governing body, which could be the chairman, board of directors, owner, proprietor, partner, head of an association, head of an institute, etc.

Responsibility to implement the directives of the governing body rests with the management and the executives, as delegated by the owners. Figure 3 illustrates the key roles, activities and relationships described in COBIT 5.

External stakeholders These are the shareholders, business partners, suppliers, regulators/government, external users, customers, external auditors, etc.

Internal stakeholders These are the members of:• Governing body—Board, chairman• Management—CEO , CFO, CIO, chief information security officer (CISO), chief privacy officer (CPO) , chief

risk officer (CRO), chief human resources officer (CHRO), chief legal officer (CLO) and all other C-level executives of the organisation

• Operation and execution—Business process owners, human resource manager, security officer, internal auditors, privacy officer, grievance officer, IT users, etc.

Note: Functional designations are given just as examples. Not every organisation will have all the designations listed. However, the individual functions will still be present and will be the responsibility of one or more individuals.

Figure 3—Key Roles, Activities and Relationships

What are the external stakeholder questions for securing SPDI?

These questions were selected from figure 7, Governance and Management Questions on IT, COBIT 5.• How do I know the enterprise is compliant with applicable rules and regulations?• How do I know the enterprise is maintaining an effective system of controls or safeguards to manage the

risks arising out of handling SPDI?

What are internal stakeholder questions for securing SPDI?

These questions were selected from figure 7, Governance and Management Questions on IT, COBIT 5.• What are the control/safeguard requirements for SPDI?• Is the SPDI that I am processing well secured?• Does IT support the enterprise in complying with regulations and service levels? How do I know whether I

am compliant with all applicable regulations?

What are the enterprise goals, as identified from the stakeholders’ needs for securing SPDI?

These goals were identified from figure 24, Mapping COBIT 5 Enterprise Goals to Governance and Management Questions, COBIT 5.

Refer to figure 4 for identifying enterprise goals from the stakeholders’ needs. The stakeholders’ needs as expressed by the questions are highlighted in the rows. The boxes containing a Y (Yes) were identified and vertical rows were highlighted resulting in identifying the four enterprise goals:• Enterprise goal 4: Compliance with external laws and regulations• Enterprise goal 7: Business service continuity and availability • Enterprise goal 9: Information-based strategic decision making• Enterprise goal 15: Compliance with internal policies

Roles, Activities and Relationships

Owners andStakeholders

GoverningBody Management

Operationsand

Execution

Instruct andAlign

Report

Set Direction

Monitor

Delegate

Accountable


23

EXPOSUREDRAFT

Figure 4—Mapping COBIT 5 Enterprise Goals to Governance and Management Questions

STAKEHOLDER NEEDS

Stak

ehol

der v

alue

of b

usin

ess

inve

stm

ents

Portf

olio

of c

ompe

titiv

e pr

oduc

ts

and

serv

ices

Man

aged

bus

ines

s ris

k (s

afeg

uard

ing

of a

sset

s)

Com

plia

nce

with

ext

erna

l law

s an

d re

gula

tions

Fina

ncia

l tra

nspa

renc

y

Cust

omer

-orie

nted

ser

vice

cul

ture

Busi

ness

ser

vice

con

tinui

ty a

nd

avai

labi

lity

Agile

resp

onse

s to

a c

hang

ing

busi

ness

env

ironm

ent

Info

rmat

ion-

base

d st

rate

gic

deci

sion

mak

ing

Optim

isat

ion

of s

ervi

ce d

eliv

ery

cost

s

Optim

isat

ion

of b

usin

ess

proc

ess

func

tiona

lity

Optim

isat

ion

of b

usin

ess

proc

ess

cost

s

Man

aged

bus

ines

s ch

ange

pr

ogra

mm

es

Oper

atio

nal a

nd s

taff

prod

uctiv

ity

Com

plia

nce

with

inte

rnal

pol

icie

s

Skill

ed a

nd m

otiv

ated

peo

ple

Prod

uct a

nd b

usin

ess

inno

vatio

n cu

lture

1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17.

1. How do I get value from the use of IT? Are end users satisfied with the quality of the IT service?

Y Y Y Y Y Y Y

2. How do I manage performance of IT? Y Y Y Y Y Y Y

3. How can I best exploit new technology for new strategic opportunities?

Y Y Y Y Y Y

4. How do I best build and structure my IT department? Y Y Y Y Y Y Y

5. How dependent am I on external providers? How well are IT outsourcing agreements being managed? How do I obtain assurance over external providers?

Y Y Y

6. What are the (control) requirements for information? Y Y Y

7. Did I address all IT-related risk? Y Y Y Y

8. Am I running an efficient and resilient IT operation? Y Y

9. How do I control the cost of IT? How do I use IT resources in the most effective and efficient manner? What are the most effective and efficient sourcing options?

Y Y Y

10. Do I have enough people for IT? How do I develop and maintain their skills, and how do I manage their performance?

Y Y Y

11. How do I get assurance over IT? Y Y

12. Is the information I am processing well secured? Y Y Y

13. How do I improve business agility through a more flexible IT environment?

Y Y Y Y

14. Do IT projects fail to deliver what they promised—and if so, why? Is IT standing in the way of executing the business strategy?

Y Y Y Y Y Y Y

Y = Yes

24


EXPOSUREDRAFT

Figure 4—Mapping COBIT 5 Enterprise Goals to Governance and Management Questions (cont.)

STAKEHOLDER NEEDS

Stak

ehol

der v

alue

of b

usin

ess

inve

stm

ents

Portf

olio

of c

ompe

titiv

e pr

oduc

ts

and

serv

ices

Man

aged

bus

ines

s ris

k (s

afeg

uard

ing

of a

sset

s)

Com

plia

nce

with

ext

erna

l law

s an

d re

gula

tions

Fina

ncia

l tra

nspa

renc

y

Cust

omer

-orie

nted

ser

vice

cul

ture

Busi

ness

ser

vice

con

tinui

ty a

nd

avai

labi

lity

Agile

resp

onse

s to

a c

hang

ing

busi

ness

env

ironm

ent

Info

rmat

ion-

base

d st

rate

gic

deci

sion

mak

ing

Optim

isat

ion

of s

ervi

ce d

eliv

ery

cost

s

Optim

isat

ion

of b

usin

ess

proc

ess

func

tiona

lity

Optim

isat

ion

of b

usin

ess

proc

ess

cost

s

Man

aged

bus

ines

s ch

ange

pr

ogra

mm

es

Oper

atio

nal a

nd s

taff

prod

uctiv

ity

Com

plia

nce

with

inte

rnal

pol

icie

s

Skill

ed a

nd m

otiv

ated

peo

ple

Prod

uct a

nd b

usin

ess

inno

vatio

n cu

lture

1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17.

15. How critical is IT to sustaining the enterprise? What do I do if IT is not available?

Y Y Y Y Y Y

16. What concrete vital primary business processes are dependent on IT, and what are the requirements of business processes?

Y Y Y Y

17. What has been the average overrun of the IT operational budgets? How often and how much do IT projects go over budget?

Y Y Y Y

18. How much of the IT effort goes to fighting fires rather than to enabling business improvements?

Y Y Y

19. Are sufficient IT resources and infrastructure available to meet required enterprise strategic objectives?

Y Y Y Y

20. How long does it take to make major IT decisions? Y Y Y Y

21. Are the total IT effort and investments transparent? Y Y Y Y

22. Does IT support the enterprise in complying with regulations and service levels? How do I know whether I am compliant with all applicable regulations?

Y Y

Y = Yes


25

EXPOSUREDRAFT

How do the enterprise goals for SPDI relate to the governance objective?

Tracing the enterprise goals in COBIT 5’s figure 5, COBIT 5 Enterprise Goals, it is possible to identify that goals 4, 7 and 15 have P (primary relationship) with the governance objective of risk optimisation. Goal 9 is more broad-based but still has P (primary relationship) with risk optimisation. Hence, it can safely be concluded that the governance objective for securing SPDI is risk optimisation. See figure 5.

Figure 5—Mapping COBIT 5 Enterprise Goals to Governance Objectives

Governance Objectives

BSC Dimension Enterprise GoalsBenefits

RealisationRisk

OptimisationResource

Optimisation

Financial 1. Stakeholder value of business investments P S

Financial 2. Portfolio of competitive products and services P P S

Financial 3. Managed business risks (safeguarding of assets) P S

Financial 4. Compliance with external laws and regulations P

Financial 5. Financial transparency P S S

Customer 6. Customer-oriented service culture P S

Customer 7. Business service continuity and availability P

Customer 8. Agile responses to a changing business environment P S

Customer 9. Information-based strategic decision making P P P

Customer 10. Optimisation of service delivery costs P P

Internal 11. Optimisation of business process functionality P P

Internal 12. Optimisation of business process costs P P

Internal 13. Managed business change programmes P P S

Internal 14. Operational and staff productivity P P

Internal 15. Compliance with internal policies P

Learning and Growth

16. Skilled and motivated people S P P

Learning and Growth

17. Product and business innovation culture

P = Primary S = Secondary

What are the IT-related goals, as mapped with enterprise goals, for securing SPDI?

Mapping COBIT 5 enterprise goals to IT-related goals is illustrated in figure 22 of COBIT 5.

Enterprise goals 4, 7, 9 and 15 (vertical columns) intersect with the following IT-related goals (horizontal rows). Only the IT goals with P (Primary Relationship) with Enterprise Goals have been selected: • IT-related goal 01: Alignment of IT and business strategy• IT-related goal 02: IT compliance and support for business compliance with external laws

and regulations• IT-related goal 04: Managed IT-related business risks• IT-related goal 10: Security of information, processing infrastructure and applications• IT-related goal 14: Availability of reliable and useful information for decision making• IT-related goal 15: IT compliance with internal policies

Refer to figure 6, Mapping Enterprise Goals to IT-related Goals.

26


EXPOSUREDRAFT

Figure 6—Mapping COBIT 5 Enterprise Goals to IT-related Goals

Enterprise Goal

Stak

ehol

der v

alue

of b

usin

ess

inve

stm

ents

Portf

olio

of c

ompe

titiv

e pr

oduc

ts a

nd s

ervi

ces

Man

aged

bus

ines

s ris

k (s

afeg

uard

ing

of a

sset

s)

Com

plia

nce

with

ext

erna

l law

s an

d re

gula

tions

Fina

ncia

l tra

nspa

renc

y

Cust

omer

-orie

nted

ser

vice

cul

ture

Busi

ness

ser

vice

con

tinui

ty a

nd a

vaila

bilit

y

Agile

resp

onse

s to

a c

hang

ing

busi

ness

env

ironm

ent

Info

rmat

ion-

base

d st

rate

gic

deci

sion

mak

ing

Optim

isat

ion

of s

ervi

ce d

eliv

ery

cost

s

Optim

isat

ion

of b

usin

ess

proc

ess

func

tiona

lity

Optim

isat

ion

of b

usin

ess

proc

ess

cost

s

Man

aged

bus

ines

s ch

ange

pro

gram

mes

Oper

atio

nal a

nd s

taff

prod

uctiv

ity

Com

plia

nce

with

inte

rnal

pol

icie

s

Skill

ed a

nd m

otiv

ated

peo

ple

Prod

uct a

nd b

usin

ess

inno

vatio

n cu

lture

1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17.

IT-related Goal Financial Customer Internal

Learning and

Growth

Fina

ncia

l

01 Alignment of IT and business strategy P P S P S P P S P S P S S

02 IT compliance and support for business compliance with external laws and regulations

S P P

03 Commitment of executive management for making IT-related decisions P S S S S S P S S

04 Managed IT-related business risk P S P S P S S S

05 Realised benefits from IT-enabled investments and services portfolio P P S S S S P S S

06 Transparency of IT costs, benefits and risk S S P S P P

Cust

omer

07 Delivery of IT services in line with business requirements P P S S P S P S P S S S S

08 Adequate use of applications, information and technology solutions S S S S S S S P S P S S

Inte

rnal

09 IT agility S P S S P P S S S P

10 Security of information, processing infrastructure and applications P P P P

11 Optimisation of IT assets, resources and capabilities P S S P S P S S S

12 Enablement and support of business processes by integrating applications and technology into business processes

S P S S S S P S S S S

13 Delivery of programmes delivering benefits, on time, on budget, and meeting requirements and quality standards

P S S S S S P S

14 Availability of reliable and useful information for decision making S S S S P P S

15 IT compliance with internal policies S S P

Lear

ning

an

d Gr

owth

16 Competent and motivated business and IT personnel S S P S S P P S

17 Knowledge, expertise and initiatives for business innovation S P S P S S S S P



27

EXPOSUREDRAFT

Figure 7 summarises the IT-related goals that are relevant to the objective of securing SPDI. IT goals 1 and 14 are too generic and not relevant for the purpose of this publication.

Figure 7—Summary of the Selected IT-related Goals

IT Goal Number IT-related Goal

Associated With IT BSC Dimension Priority Comments

01 Alignment of IT and business strategy Financial P Not relevant

02 IT compliance and support for business compliance with external laws and regulations Financial P Accepted

04 Managed IT-related business risk Financial P Accepted

10 Security of information, processing infrastructure and applications Internal P Accepted

14 Availability of reliable and useful information for decision making Internal P Not relevant

15 IT compliance with internal policies Internal P Accepted

Conclusion

This chapter identified the external and internal stakeholders who are concerned with securing SPDI. From this basis, the goals cascade leading the IT processes was traced:


As a result of the cascade, the four key IT-related goals were identified that will help to meet the enterprise goals and address the stakeholders’ concerns.

The next chapter will address building the reasonable security practices and procedures with the help of the seven COBIT 5 enablers. Enabler 2 : Processes will direct the selection of the relevant IT processes by mapping the selected IT-related goals (figure 7) with the IT processes.

28


EXPOSUREDRAFT

chAPter 4cobIt 5 enAblers for securIng sPdIReasonable Security Practices and Procedures

This chapter begins with an introduction of the COBIT 5 enablers. These seven enablers provide the reasonable security practices and procedures towards securing SPDI. Each enabler is then explained in detail with the objective of securing SPDI and meeting the enterprise goals.• Enabler 1: Principles, Policies and Frameworks. This enabler has a number of outlines that could be used to create

various policies and procedures for securing SPDI. The linkage to the IT Act as well as various COBIT 5 processes is provided in this section.

• Enabler 2: Processes. The ten processes that are essential for securing SPDI are identified in this section. Elaboration of these processes is in COBIT 5: Enabling Processes and COBIT 5 for Information Security. These processes are referred to in the policies and procedures identified in Enabler 1.

• Enabler 3: Organisational Structures. This enabler gives details about the specific organisational structure and roles and responsibilities of people essential for securing SPDI.

• Enabler 4: Culture, Ethics and Behaviour. The type of behavior that is conducive to create an appropriate culture leading to the security of SPDI is explained in this section.

• Enabler 5: Information. This enabler discusses various information quality goals and the best practices to achieve them for securing SPDI.

• Enabler 6: Services, Infrastructure and Applications. This enabler explains various service capabilities required to secure SPDI.

• Enabler 7: People, Skills and Competencies. The security of SPDI cannot be achieved through processes and technologies alone. Skills, competencies and requisite training also must be imparted at all levels. This enabler explains various training aspects to ensure such competencies.

COBIT 5 Enablers

Enablers are factors that, individually and collectively, influence whether something will work—in this case, governance and management over enterprise IT. Enablers are driven by the goals cascade, i.e., higher-level IT-related goals define what the different enablers should achieve.

The COBIT 5 framework describes seven categories of enablers (see figure 8).

Figure 8—COBIT 5 Enterprise Enablers

2. Processes3. Organisational

Structures

1. Principles, Policies and Frameworks

6. Services,Infrastructure

and Applications

7. People,Skills and

Competencies

Resources

5. Information

4. Culture, Ethicsand Behaviour

Chapter 4 COBIt 5 enaBlers fOr seCurIng spDI

29

EXPOSUREDRAFT

COBIT 5 Enabler 1: Principles, Policies and Frameworks

Fair information practices of OECD Principles involved in securing SPDI are broadly based on the eight ‘fair information practices’ of OECD:9 1. Collection Limitation Principle. There should be limits to the collection of personal data and any such

data should be obtained by lawful and fair means and, where appropriate, with the knowledge or consent of the data subject.

2. Data Quality Principle. Personal data should be relevant to the purposes for which they are to be used, and, to the extent necessary for those purposes, should be accurate, complete and kept up-to-date.

3. Purpose Specification Principle. The purposes for which personal data are collected should be specified not later than at the time of data collection and the subsequent use limited to the fulfillment of those purposes or such others as are not incompatible with those purposes and as are specified on each occasion of change of purpose.

4. Use Limitation Principle. Personal data should not be disclosed, made available or otherwise used for purposes other than those specified, except:

a) With the consent of the data subject, or b) By the authority of law.5. Security Safeguards Principle. Personal data should be protected by reasonable security safeguards

against such risks as loss or unauthorised access, destruction, use, modification or disclosure of data.6. Openness Principle. There should be a general policy of openness about developments, practices and

policies with respect to personal data. Means should be readily available of establishing the existence and nature of personal data, and the main purposes of their use, as well as the identity and usual residence of the data controller.

7. Individual Participation Principle. An individual should have the right: a) To obtain from a data controller, or otherwise, confirmation of whether or not the data controller has

data relating to him b) To have communicated to him, data relating to him: i) Within a reasonable time ii) At a charge, if any, that is not excessive iii) In a reasonable manner, and iv) In a form that is readily intelligible to him c) To be given reasons if a request made under subparagraphs (a) and (b) is denied, and to be able to

challenge such denial, and d) To challenge data relating to him and, if the challenge is successful to have the data erased, rectified,

completed or amended.8. Accountability Principle. A data controller should be accountable for complying with measures which

give effect to the principles stated above.

Policies and procedures required for securing SPDI

1. Privacy policy for SPDI2. Procedures for the privacy policy for SPDI3. SPDI security policies4. SPDI security procedures

1. Privacy policy for SPDI Goals• Provide direction on collection, storage, usage, transfer and destruction of SPDI as per the IT Act.

Validity• Applicable to the entire enterprise including the entities external to the enterprise that handle SPDI on

behalf of the enterprise

Update and Revalidation• To be updated by CPO upon any changes to the IT Act or Rules • To be revalidated by CPO upon any change of business activities handling SPDI or at least once a year

ScopeThe privacy policy should include answers to the following questions based on the requirements of IT Act summarised in the indicated checklists.

Does the policy explain the type of personal information that we collect?

Checklist—Chapter 1, Item 3



9 Fair Information Practices from OECD Guidelines governing the protection of privacy and transborder flow of personal data, www.oecd.org

30


EXPOSUREDRAFT

Have we obtained the consent? Checklist—Chapter 1, Item 9


Does the policy explain why we collect and use the personal data?

Checklist —Chapter 1, Item 10

1. Have we defined the purpose for collection of sensitive personal data?2. Is such purpose connected with one or more of our functions or activities? 3. Are the data collected necessary for such function or activity? 4. Who (in the organisation) considered it necessary? Is the reasoning for such consideration duly documented?

Have we disclosed that we are collecting the data?


1. Have we disclosed that we are collecting the data?2. Have we disclosed the purpose for such collection? Is the purpose stated broad enough to cover potential

future uses of the data? 3. Have we indicated who will be the recipients of the data? Is such indication broad enough to cover all

contemplated future recipients?4. Have we indicated the full name and address of the agency collecting the data and of the agency that will

retain the information?5. Most importantly, have the appropriate management personnel determined the steps that are needed

to ensure the aforesaid and whether such steps are reasonable in the circumstances? Have they documented their reasons for considering these steps reasonable and adequate?

Have we disclosed the retention policy?


1. Do we have a retention policy for sensitive personal data?2. Does that policy indicate how long we will retain such data or different types of such data?3. Do we have a mechanism to determine whether such retention periods are no longer than is required for

the purposes for which the information may lawfully be used or is otherwise required under any other law that may apply? Who (in the organisation) decides this and how? Are the reasons for such retention periods documented?

4. Do we have mechanisms to ensure retention per such policy?5. Do we have mechanisms for checking if the data are used only for the stated purposes?6. Are these mechanisms tested and reviewed?

Have we stated that the review of personal information by the information provider is permitted?





Are there options not to provide the data being sought?


1. Do we give the provider of personal data an option to not provide the data?2. Do we give this option before collecting the data?3. Do we give the provider of data an option of withdrawing consent for collection or use of the data? 4. Is the option for withdrawal of consent available at any time?

Have the contact details of the grievance officer been provided?





Have the conditions been explained under which the data could be disclosed?


1. Do we disclose sensitive personal data to third parties? 2. Are such third parties identified and listed?3. Do we have the prior permission of the providers of the sensitive personal information for such disclosure? 4. Or, is there a contract with the provider of the sensitive personal information that allows such disclosure? 5. Or, is such disclosure necessary for compliance with a legal obligation? 6. Is there a mechanism to review requests for disclosure of sensitive personal information in compliance

with a legal obligation (e.g., in ‘returns’ or forms filed with the state or central government)?


31

EXPOSUREDRAFT

Have the conditions been explained under which the data could be transferred to government agencies or third parties?



2. Are the people handling such matters trained to: • Identify such requests? • Determine if the concerned government agency is mandated by the law to seek such data? • Determine if the purpose of the request is clear and as per the law

(see note below)? • Determine if the agency has stated specifically that such shared

data will not be published or shared with any other person?





1. Do we transfer sensitive personal data to any other body corporate or person in India or abroad?2. Do we have a mechanism in place to check if the proposed transferee ensures the same level of data

protection as required under the Indian rules?3. Do we have a mechanism in place to check if such transfers are made only: • For the performance of lawful contracts between us and the provider of the information? • Or, where the provider of information has consented to such transfer?

Has it been stated that the data will not be published?


1. Do we have mechanisms in place to: • Review all materials published by us? • Check if any sensitive personal data are part of such materials? • Mask or redact such sensitive personal data?

Have the reasonable security policies and procedures that are adopted to ensure the security of SPDI been explained?


1. Do we have in place appropriate information security policies?2. Do such policies contain managerial, technical, operational and physical security control measures? 3. Are such measures commensurate with the information assets being protected and the nature of

our business?4. Do we have in place a comprehensive information security programme?5. Is the information security programme well documented?6. Do we consistently implement such security practices and standards?7. Can we demonstrate, whenever called upon to do so by an agency mandated under the law, that we have

implemented security control measures as per our documented information security programme and policies? (Such requests can be anticipated whenever there is an information security breach.)

Have any penalties been defined for the breach of the privacy policy by internal or external entities handling the SPDI?

As per chapter 4, Enabler 4: Culture, ethics and behaviour, section on Leadership, first bullet: Influencing behaviour, through communication, enforcement, and rules and norms:

Define penalty for breach of SPDI by the internal or external entities in increasing order of severity based on business as well as reputational impact. For example:• Verbal reprimand• Written notice• Financial penalty• Disciplinary action• Termination of contract or employment etc.

32


EXPOSUREDRAFT

2. Procedures for privacy policy

2.1 Procedure for identifying SPDI Key points:• Create a master list of some or all the following items of SPDI used in the enterprise: – Password – Financial information such as bank account, credit card or debit card, or other payment

instrument details – Physical, physiological and mental health condition – Sexual orientation – Medical records and history – Biometric information• Give examples of each of the items for clarification.

Responsibility: • CPO




2.2 Procedure for identifying business processes using SPDI

As per APO12.03, COBIT 5 and COBIT 5 for Information Security:

Key points:• Make an inventory of – Business processes handling SPDI – Applications handling SPDI – Critical manual records handling SPDI – Personnel who handle SPDI – Vendors/suppliers/outsourcers who handle SPDI

Responsibility: • CPO, assisted by CHRO and business heads

2.3 Procedure for obtaining consent Key points:• Mention the purpose of obtaining the SPDI• Make a checklist for how the consent is obtained. – Consent in writing – Consent by a click on a button of a web form – Consent by email – Consent by fax – Consent through SMS – Consent by any other means that is not ambiguous• Maintain a record of the obtained consents.

Responsibility:• CPO



2.4 Procedure for allowing access to the SPDI for review by the provider

Key points:• Provide a copy of the SPDI pertaining to the information provider on request for review.• Accept the review comments.• Correct or update the SPDI if requested by the provider.• Give feedback to the provider.







33

EXPOSUREDRAFT

2.5 Grievances redressal procedure Key points:• Appoint a grievances officer.• Publish the duties and contact details of the grievances officer prominently on the web site.• Notify to the complainant the complaint number and the date of receipt.• Resolve to reply to the complaint within one month of the receipt date.






2.6 Procedure for providing access to government agencies

Key points:• Check the following: – The request is in writing. – The request is from a government agency mandated under the law. – The purpose of seeking SPDI is clearly mentioned. The purpose could either be verification of identity,

or prevention, detection, and investigation including cyberincidents, prosecution, and punishment of offenders.

– An assurance that the SPDI will not be published or shared without legal authorisation is given in the request.

– If it is an order under the law, then SPDI must be shared in compliance with such order.




2. Are the people handling such matters trained to: • Identify such requests? • Determine if the concerned government agency is mandated by the law to seek such data? • Determine if the purpose of the request is clear and as per the law

(see note below)? • Determine if the agency has stated specifically that such shared

data will not be published or shared with any other person?

2.7 Procedure for transferring/sharing data with third parties

Key points:• Check the following: – Get agreement from the third parties with whom the enterprise shares the SPDI to refrain from further

disclosure of such data. – Get agreement that the enterprise will be allowed to conduct audit or surprise checks on the third parties

to confirm the above.





2.8 Procedure for penalties for any breaches by internal or external entities handling SPDI

As per chapter 4, Enabler 4:

Key points:• Penalty for breach of SPDI by the internal or external entities in increasing order of severity based on

business as well as reputational impact: – Verbal warning to the entities – Written warning to the entities – Financial penalty to the entities – Termination of the entities – Prosecution of the entities• Publish the penalties in employee contracts as well external entity contracts.

Responsibility:• CHRO

34


EXPOSUREDRAFT

2.9 Procedure for meeting intrinsic quality goals for SPDI


Key points:• SPDI should be correct and reliable: – Ask the provider to confirm the accuracy of the information provided. – Verify against a reliable data base (e.g., PAN card database). – Make no modification to the information unless confirmed by the provider. – Use range checks, limit checks and/or reasonableness checks. – Use encrypted hashes for checking the integrity of stored SPDI.

Responsibility:• CIO

2.10 Procedure for meeting contextual and representational quality


Key points:• Confirm that the SPDI is collected only for lawful purposes connected with the functions or activities of the

enterprise.• Confirm that the collection and use of the SPDI is relevant to the identified purpose only.• Confirm that the SPDI is free from error, accurate and up to date.


2.11 Confidentiality agreement for outsourcing or insourcing of services for SPDI


Key points:• A confidentiality agreement is signed with outsourcing or third parties providing any service involving the

SPDI.• A similar agreement should also be signed even for insourcing arrangements, e.g., between the business

unit collecting the SPDI and the data center processing it.

Responsibility:• Chief legal officer (CLO), assisted by CPO

3. SPDI security management policies

3.1 SPDI security policy As per APO13 and DSS05 in COBIT 5 and COBIT 5 for Information Security:

Goals• Provide direction on management of SPDI security for the enterprise.• Align the SPDI security policy with other policies of the enterprise (e.g., HR policy).• Ensure that the SPDI security plan is established, accepted and communicated throughout the enterprise.

Validity• Applicable to the entire enterprise, including entities external to the enterprise responsible for handling

SPDI on behalf of the enterprise

Update and Revalidation• To be updated/revalidated by the CISO upon any change in the business activities handling SPDI or at

least once a year

Scope for the Policy• A definition of SPDI security for the enterprise• The responsibilities associated with SPDI security• The vision regarding SPDI security, accompanied by appropriate goals and metrics and an explanation of

how the vision is supported by the information security culture and awareness• Explanation of how the SPDI security policy aligns with other high-level policies• Elaboration on specific SPDI security topics such as data management, risk assessment and compliance

with the IT Act


35

EXPOSUREDRAFT

3.2 Ethics policy for SPDI As per chapter 4, Enabler 4:

Goals• Identify a set of behaviours supporting the security of SPDI.• Influence behaviours through leadership.• Influence behaviours through incentives and rewards.

Validity• Applicable to the entire enterprise

Update and Revalidation• To be updated/revalidated by CPO upon any change in business activities handling SPDI or at least

once a year

Scope for the Policy• The ethics policy should identify the individual-level behaviour expected by the organisation regarding the

security of the SPDI.• The ethics policy should explain how the three levels of enterprise management will influence

this behavior.

3.3 Risk management policy As per EDM03 and APO12 in COBIT 5 and COBIT 5 for Information Security:

Goals• SPDI-related risks are defined, communicated and known.• The enterprise manages these risks effectively and efficiently.

Validity• Applicable to the entire enterprise

Update and Revalidation• To be updated/revalidated by CRO, assisted by CPO, upon any change in business activities handling SPDI

or at least once a year

Scope for the Policy• Organisational risk management plan – Scope of the risk management policy – Roles and responsibilities of people involved – Risk management methodologies to evaluate, direct and monitor risk – Tools and techniques to mitigate risk – Creation of a risk repository • SPDI risk profile

3.4 SPDI incidence response policy As per DSS02, COBIT 5 and COBIT 5 for Information Security:

Goals• To respond to any incidence involving SPDI in a timely manner to contain and mitigate the damage and

recover business activities



Update and Revalidation• To be updated/revalidated by CISO, assisted by CPO, upon any change in business activities handling

SPDI or at least once a year

Scope for the policy• A definition of an SPDI-related security incident• A statement of how such incidents will be handled• Requirements for the establishment of the SPDI incident response team, with organisational roles

and responsibilities• Requirements for the creation of a tested SPDI incident response plan, which will provide documented

procedures and guidelines for: – Criticality of the incidents – Reporting and escalation process – Recovery (including):

. Recovery time objectives (RTOs) for return to the trusted state – Investigation and preservation of process – Testing and training – Post-incident meetings to document root cause analysis and document enhancements of SPDI security

practices to prevent future similar events – Incident documentation and closing

36


EXPOSUREDRAFT

3.5 SPDI security safeguards review policy

As per MEA02, COBIT 5 and COBIT 5 for Information Security:

Goals• To get independent assurance that the system of internal controls is operational and effective for securing

the SPDI in the enterprise



Update and Revalidation• To be updated/revalidated by chief internal auditor (CIA), assisted by CISO and CPO, upon any change in

business activities handling SPDI or at least once a year

Scope for the Policy• Plan, organise and maintain standards for internal control assessment and assurance activities.• Provide independent assurance to the stakeholders on the adequacy of the system of internal controls and

thus ensure trust in the operations of securing SPDI.

3.6 Compliance policy for SPDI with IT Act


Goals• Enterprise is compliant with the requirements of IT Act



Update and Revalidation• To be updated/revalidated by CLO, assisted by CPO, upon any change in the IT Act or Rules or at least

once a year

Scope for the Policy• Identify compliance requirements with the IT Act as amended and the latest Rules.• Optimise response to the compliance requirements.• Confirm compliance with the IT Act as amended.• Obtain assurance of compliance with the IT Act as amended.

3.7 Outsourcing and insourcing policy for SPDI


Goals• The SPDI is secured by all external or internal entities providing any service related to SPDI.


behalf of the enterprise or internal departments providing any services related to handling SPDI

Update and Revalidation• To be updated/revalidated by CIA, assisted by CISO and CPO, upon any change in business activities

handling SPDI or at least once a year

Scope for the Policy• Provide assurance to stakeholders on the adequacy of the system of internal controls maintained by the

outsourcing parties and thus ensure trust in operations of securing SPDI.• Provide assurance to stakeholders on the adequacy of the system of internal controls maintained by the

insourcing parties and thus ensure trust in operations of securing SPDI.

4. SPDI security procedures

4.1 Risk management procedure As per EDM03.02, COBIT 5 and COBIT 5 for Information Security:

Key points:• Evaluate risk management.• Direct risk management.• Monitor risk management.

Responsibility:• CRO


37

EXPOSUREDRAFT

4.2 Procedure for collection, classification and analysis of SPDI-related risk

As per APO12, COBIT 5 and COBIT 5 for Information Security:

Key points:• Collect data.• Analyse risks.• Maintain a risk profile.• Articulate risk.• Define a risk management action portfolio.• Respond to risk.

Responsibility:• CRO

4.3 Procedure for estimating business impact for SPDI-related risk

As per DSS04.02, COBIT 5 and COBIT 5 for Information Security:

Key points:• Identify business impact of compromise of SPDI.

Responsibility:• Business head

4.4 Procedure to identify scope, boundary of the SPDI security management system

As per APO13.01, COBIT 5 and COBIT 5 for Information Security:

Key points:• Establish and maintain an SPDI security management system.• Define and manage an SPDI security risk treatment plan.• Monitor and review the SPDI security management system.

Responsibility:• CISO

4.5 Procedure for SPDI incident response

As per DSS02, COBIT 5 and COBIT 5 for Information Security:

Key points:• Define incidents and service request classification scheme.• Record, classify and prioritise requests and incidents.• Verify, approve and fulfil service requests.• Investigate, diagnose and allocate incidents.• Resolve and recover from incidents.• Close service requests and incidents.• Track status and produce reports.

Responsibility:• Grievance officer, assisted by head of operations

4.6 Procedure for protection against malware


Key points:• Implement and maintain effective measures, such as virus control and security patches, to protect SPDI

from malware.


4.7 Procedure for managing network and connectivity security


Key points:• Manage network and connectivity security to prevent attacks on SPDI.


4.8 Procedure for managing endpoint security


Key points:• Secure endpoints at a level adequate to protect SPDI.


38


EXPOSUREDRAFT

4.9 Procedure for managing user identity and logical access, to ensure security/accessibility of SPDI

As per DSS05.04, COBIT 5 Framework and COBIT 5 for Information Security

Key points:• Manage user identity and logical access.


4.10 Procedure for managing physical access to SPDI assets

As per DSS05.05, COBIT 5 and COBIT 5 for Information Security :

Key points:• Manage physical access to IT assets storing SPDI.


4.11 Procedure for managing sensitive documents and output devices


Key points:• Manage sensitive documents and output devices handling SPDI.


4.12 Procedure for monitoring the infrastructure for security-related events


Key points:• Monitor the infrastructure for security-related events.• Collect evidence as per Indian evidence rules.


4.13 Procedure for reviewing the SPDI security controls and safeguards


Key points:• Monitor internal controls and safeguards for SPDI security.• Review business process controls effectiveness.• Perform control self-assessment.• Identify and report control deficiencies.• Ensure that assurance providers are independent and qualified.• Plan assurance activities.• Scope assurance activities.• Execute assurance activities.

Responsibility:• CIA

4.14 Procedures for reviewing the SPDI controls and safeguards against IT Act requirements


Key points:• Identify compliance requirements with the IT Act and the latest Rules.• Optimise response to the compliance requirements.• Confirm compliance with the IT Act.• Obtain assurance of compliance with the IT Act.

Responsibility:• CIA

4.15 Procedure for secure storage of SPDI


Key points:• Securely store hard copies containing SPDI.• Securely store SPDI in digital form on backup storage media such as disk drives, USB drives, tapes, DATs

or in the cloud.• Securely store SPDI in digital form on servers (mail servers, database servers, web servers), computers,

notebook PCs, mobile phones, tablet PCs and in cloud-based services.



39

EXPOSUREDRAFT

4.16 Procedure for destruction /disposal of SPDI


Key points:• Securely shred hard copies containing SPDI.• Securely erase SPDI in digital form on storage media.• Securely erase SPDI in digital form on servers, computers, notebook PCs, mobile phones, table PCs and

from cloud-based services.• Securely destroy CDs/DVDs or any such media that cannot be erased but contain SPDI.


4.17 Procedure for secure transmission of SPDI


Key points:• Securely send SPDI in hard copy.• Securely encrypt and transmit SPDI in digital form.


4.18 Procedure for maintaining audit log for access to SPDI


Key points:• Maintain audit logs for access to SPDI.• Archive the logs for a period defined by the law, rules, regulations or notification, as applicable.• Provide access to the logs to only the authorised persons.


4.19 Procedure for maintaining security at the empirical layer for SPDI


Key points:• Mask the SPDI when collected through online interfaces.• Transmit SPDI only after encryption.• Anonymise SPDI being used for statistical analysis.• De-identify SPDI being used for research or similar purposes.


4.20 Procedure for maintaining security at the syntactic layer for SPDI


Key points:• Use XML encryption or similar secure options for secure communication using SPDI.


4.21 Procedure for maintaining security at the semantic layer for SPDI


Key points:• Create SPDI as a distinct information type to provide a higher level of security.• Create an indicator to display the currency of SPDI.• Display minimum information as required by the activity or the person whose information is being displayed.


4.22 Procedure for maintaining security at the pragmatic layer for SPDI


Key points:• Define the retention period for SPDI before it is destroyed.• Identify whether the SPDI is operational or historical.• Identify if the SPDI creates new knowledge or confirms existing knowledge (information vs. confirmation).• Identify the information that is required to precede this information.


40


EXPOSUREDRAFT

4.23 Procedure for maintaining security at the social-world layer


Key points:• Identify information unsuitable for display.• Prevent disclosure of such information.


4.24 Service level agreement for outsourcing or insourcing of services for SPDI


Key points:• Identify the services that could be outsourced.• Identify the services that could be insourced.• Identify the expected service levels for the services.• Sign the service level agreement.• Sign the confidentiality agreement.

Responsibility:• Business heads• CLO

4.25 SPDI training programmes for all levels in the organisation


Key points:• Create appropriate training programmes for all levels: – Customers whose SPDI is being collected – General staff of the enterprise – Operations and execution team – Management – Board members• Conduct the training programmes with competent trainers.• Maintain records of the training programmes.

Responsibility:• CHRO


41

EXPOSUREDRAFT

Processes for Management of Enterprise IT

Evaluate, Direct and Monitor

Processes for Governance of Enterprise IT

Align, Plan and Organise Monitor, Evaluateand Assess

Build, Acquire and Implement

Deliver, Service and Support

EDM01 EnsureGovernance

Framework Settingand Maintenance

APO01 Managethe IT Management

Framework

APO08 ManageRelationships

APO02 ManageStrategy

APO09 ManageService

Agreements

APO03 ManageEnterprise

Architecture

APO10 ManageSuppliers

APO04 ManageInnovation

APO11 ManageQuality

APO05 ManagePortfolio

APO12 ManageRisk

APO06 ManageBudget and Costs

APO07 ManageHuman Resources

MEA01 Monitor,Evaluate and Assess

Performance andConformance


the System of InternalControl


Compliance WithExternal Requirements

APO13 ManageSecurity

DSS01 ManageOperations

DSS02 ManageService Requests

and Incidents

DSS03 ManageProblems

DSS04 ManageContinuity

DSS05 ManageSecurityServices

DSS06 ManageBusiness

Process Controls

BAI01 ManageProgrammes and

Projects

BAI08 ManageKnowledge

BAI02 ManageRequirements

Definition

BAI09 ManageAssets

BAI03 ManageSolutions

Identificationand Build

BAI010 ManageConfiguration

BAI04 ManageAvailability

and Capacity

BAI05 ManageOrganisational

ChangeEnablement

BAI06 ManageChanges

BAI07 ManageChange

Acceptance andTransitioning

EDM02 EnsureBenefits Delivery

EDM03 EnsureRisk Optimisation

EDM04 EnsureResource

Optimisation

EDM05 EnsureStakeholder

Transparency

COBIT 5 Enabler 2: Processes

The COBIT 5 process reference model divides the governance and management processes of enterprise IT into two main process domains:• Governance—Contains five governance processes; within each process—evaluate, direct and monitor (EDM)• Management—Contains four domains in line with the responsibility areas of plan, build, run and monitor (PBRM), and

provides end-to-end coverage of IT. These domains are: – Align, Plan and Organise (APO) – Build, Acquire and Implement (BAI) – Deliver, Service and Support (DSS) – Monitor, Evaluate and Assess (MEA)

Figure 9 shows the complete set of 37 governance and management processes within COBIT 5.

Figure 9—COBIT 5 Illustrative Governance and Management Processes

42


EXPOSUREDRAFT

IT Processes Applicable for Securing SPDI

The IT processes applicable for securing SPDI are identified using the goal cascade as explained in chapter 2:


Enabler 2 defines the IT processes. Selection of the relevant IT processes has been done by mapping IT-related goals (vertical columns) with the IT processes (horizontal rows), where the intersection of IT-related goals and IT processes is marked P (primary relationship). Ten processes (out of a total of 37 processes) have been identified to help in meeting the four IT-related goals.

See figure 10 below (based on figure 23, Appendix C, of COBIT 5).

Figure 10—Mapping COBIT 5 IT-related Goals to Processes

IT-related Goal

Alig

nmen

t of I

T an

d bu

sine

ss s

trate

gy

IT c

ompl

ianc

e an

d su

ppor

t for

bus

ines

s

com

plia

nce

with

ext

erna

l law

s an

d re

gula

tions

Com

mitm

ent o

f exe

cutiv

e m

anag

emen

t fo

r mak

ing

IT-r

elat

ed d

ecis

ions

Man

aged

IT-r

elat

ed b

usin

ess

risk

Real

ised

ben

efits

from

IT-e

nabl

ed

inve

stm

ents

and

ser

vice

s po

rtfol

io

Tran

spar

ency

of I

T co

sts,

ben

efits

and

risk

Deliv

ery

of IT

ser

vice

s in

line

with

bu

sine

ss re

quire

men

ts

Adeq

uate

use

of a

pplic

atio

ns, i

nfor

mat

ion

an

d te

chno

logy

sol

utio

ns

IT a

gilit

y

Secu

rity

of in

form

atio

n, p

roce

ssin

g

infra

stru

ctur

e an

d ap

plic

atio

ns

Optim

isat

ion

of IT

ass

ets,

reso

urce

s

and

capa

bilit

ies

Enab

lem

ent a

nd s

uppo

rt of

bus

ines

s pr

oces

ses

by in

tegr

atin

g ap

plic

atio

ns a

nd te

chno

logy

into

bu

sine

ss p

roce

sses

Deliv

ery

of p

rogr

amm

es d

eliv

erin

g be

nefit

s,

on ti

me,

on

budg

et, a

nd m

eetin

g re

quire

men

ts

and

qual

ity s

tand

ards

Avai

labi

lity

of re

liabl

e an

d us

eful

in

form

atio

n fo

r dec

isio

n m

akin

g

IT c

ompl

ianc

e w

ith in

tern

al p

olic

ies

Com

pete

nt a

nd m

otiv

ated

bu

sine

ss a

nd IT

per

sonn

el

Know

ledg

e, e

xper

tise

and

initi

ativ

es fo

r bu

sine

ss in

nova

tion

01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17

COBIT 5 Process Financial Customer Internal

Learning and

Growth

Eval

uate

, Dire

ct a

nd M

onito

r EDM01 Ensure Governance Framework Setting and Maintenance

P S P S S S P S S S S S S S S S

EDM02 Ensure Benefits Delivery P S P P P S S S S S S P

EDM03 Ensure Risk Optimisation S S S P P S S P S S P S S

EDM04 Ensure Resource Optimisation S S S S S S S P P S P S

EDM05 Ensure Stakeholder Transparency S S P P P S S S S

Alig

n, P

lan

and

Orga

nise

APO01 Manage the IT Management Framework P P S S S P S P S S S P P P

APO02 Manage Strategy P S S S P S S S S S S S S P

APO03 Manage Enterprise Architecture P S S S S S S P S P S S S

APO04 Manage Innovation S S P P P P S S P

APO05 Manage Portfolio P S S P S S S S S P S

APO06 Manage Budget and Costs S S S P P S S S S

APO07 Manage Human Resources P S S S S S S P P S P P

APO08 Manage Relationships P S S S S P S S P S S S P

APO09 Manage Service Agreements S S S S P S S S S S P S

APO10 Manage Suppliers S P S S P S P S S S S S S

APO11 Manage Quality S S S P P S S S P S S S S

APO12 Manage Risk P P P S S S P P S S S S

APO13 Manage Security P P P S S P P



43

EXPOSUREDRAFT

Figure 10—Mapping COBIT 5 IT-related Goals to Processes (cont.)

IT-related Goal

Alig

nmen

t of I

T an

d bu

sine

ss s

trate

gy

IT c

ompl

ianc

e an

d su

ppor

t for

bus

ines

s

com

plia

nce

with

ext

erna

l law

s an

d re

gula

tions

Com

mitm

ent o

f exe

cutiv

e m

anag

emen

t fo

r mak

ing

IT-r

elat

ed d

ecis

ions

Man

aged

IT-r

elat

ed b

usin

ess

risk

Real

ised

ben

efits

from

IT-e

nabl

ed

inve

stm

ents

and

ser

vice

s po

rtfol

io

Tran

spar

ency

of I

T co

sts,

ben

efits

and

risk

Deliv

ery

of IT

ser

vice

s in

line

with

bu

sine

ss re

quire

men

ts

Adeq

uate

use

of a

pplic

atio

ns, i

nfor

mat

ion

an

d te

chno

logy

sol

utio

ns

IT a

gilit

y

Secu

rity

of in

form

atio

n, p

roce

ssin

g

infra

stru

ctur

e an

d ap

plic

atio

ns

Optim

isat

ion

of IT

ass

ets,

reso

urce

s

and

capa

bilit

ies

Enab

lem

ent a

nd s

uppo

rt of

bus

ines

s pr

oces

ses

by in

tegr

atin

g ap

plic

atio

ns a

nd te

chno

logy

into

bu

sine

ss p

roce

sses

Deliv

ery

of p

rogr

amm

es d

eliv

erin

g be

nefit

s,

on ti

me,

on

budg

et, a

nd m

eetin

g re

quire

men

ts

and

qual

ity s

tand

ards

Avai

labi

lity

of re

liabl

e an

d us

eful

in

form

atio

n fo

r dec

isio

n m

akin

g

IT c

ompl

ianc

e w

ith in

tern

al p

olic

ies

Com

pete

nt a

nd m

otiv

ated

bu

sine

ss a

nd IT

per

sonn

el

Know

ledg

e, e

xper

tise

and

initi

ativ

es fo

r bu

sine

ss in

nova

tion

01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17

COBIT 5 Process Financial Customer Internal

Learning and

Growth

Build

, Acq

uire

and

Impl

emen

t

BAI01 Manage Programmes and Projects P S P P S S S S P S S

BAI02 Manage Requirements Definition P S S S S P S S S S P S S S

BAI03 Manage Solutions Identification and Build S S S P S S S S S S

BAI04 Manage Availability and Capacity S S P S S P S P S

BAI05 Manage Organisational Change Enablement S S S S P S S S P S P

BAI06 Manage Changes S P S P S S P S S S S S S

BAI07 Manage Change Acceptance and Transitioning S S S P S P S S S S

BAI08 Manage Knowledge S S S S P S S S S P

BAI09 Manage Assets S S P S S S P S S

BAI10 Manage Configuration P S S S S S P P S

Deliv

er, S

ervi

ce a

nd S

uppo

rt DSS01 Manage Operations S P S P S S S P S S S S

DSS02 Manage Service Requests and Incidents P P S S S S S

DSS03 Manage Problems S P S P S S P S P S S

DSS04 Manage Continuity S S P S P S S S S S P S S S

DSS05 Manage Security Services S P P S S P S S S S

DSS06 Manage Business Process Controls S P P S S S S S S S S

Mon

itor,

Eval

uate

and

Ass

ess MEA01 Monitor, Evaluate and

Assess Performance and Conformance

S S S P S S P S S S P S S P S S

MEA02 Monitor, Evaluate and Assess the System of Internal Control

P P S S S S S P S

MEA03 Monitor, Evaluate and Assess Compliance With External Requirements

P P S S S S S


44


EXPOSUREDRAFT

The identified IT processes for securing SPDI are:• Evaluate, Direct and Monitor (EDM) – EDM03 Ensure Risk Optimisation• Align, Plan and Organise (APO) – AP001 Manage the IT Management Framework – AP012 Manage Risk – AP013 Manage Security• Build, Acquire and Implement (BAI) – BAI06 Manage Changes• Deliver, Service and Support (DSS) – DSS02 Manage Service Requests and Incidents – DSS04 Manage Continuity – DSS05 Manage Security Services• Monitor, Evaluate and Assess (MEA) – MEA02 Monitor, Evaluate and Assess the System of Internal Control – MEA03 Monitor, Evaluate and Assess Compliance with External Requirements

Detailed process-related content for COBIT 5’s governance and management processes is provided in COBIT 5: Enabling Processes. For each process the following information is included:• Process identification: – Process label—The domain prefix (EDM, APO, BAI, DSS, MEA) and the process number – Process name—A short description, indicating the main subject of the process – Area of the process—Governance or management – Domain name• Process description—An overview of what the process does and a high-level description of how the process

accomplishes its purpose• Process purpose statement—A description of the overall purpose of the process• Goals cascade information—Reference and description of the IT-related goals that are primarily supported by the

process, and metrics to measure the achievement of the IT-related goals• Process goals and metrics—A set of process goals and a limited number of example metrics• RACI chart—A suggested assignment of level of responsibility for process practices to different roles and structures.

The enterprise roles listed are shaded darker than the IT roles. The different levels of involvement are: – R(esponsible)—Who is getting the task done? This refers to the roles taking the main operational stake in fulfilling

the activity listed and creating the intended outcome. – A(ccountable)—Who accounts for the success of the task? This assigns the overall accountability for getting the

task done (Where does the buck stop?). Note that the role mentioned is the lowest appropriate level of accountability; there are, of course, higher levels that are accountable, too. To enable empowerment of the enterprise, accountability is broken down as far as possible. Accountability does not indicate that the role has no operational activities; it is very likely that the role gets involved in the task. As a principle, accountability cannot be shared.

– C(onsulted)—Who is providing input? These are key roles that provide input. Note that it is up to the accountable and responsible role(s) to obtain information from other units or external partners as well. However, inputs from the roles listed are to be considered and, if required, appropriate action has to be taken for escalation, including the information of the process owner and/or the steering committee.

– I(nformed)—Who is receiving information? These are roles that are informed of the achievements and/or deliverables of the task. The accountable role, of course, should always receive appropriate information to oversee the task, as do the responsible roles for their area of interest.

• Detailed description of the process practices—For each practice: – Practice title and description – Practice inputs and outputs, with indication of origin and destination – Process activities, further detailing the practices• Related guidance—References to other standards and direction to additional guidance


45

EXPOSUREDRAFT

COBIT 5 Enabler 3: Organisational Structures

Who are the stakeholders for SPDI? A stakeholder is anyone who has a responsibility for, an expectation from or some other interest in the enterprise, e.g., shareholders, users, government, suppliers, customers and the public.

For SPDI, the stakeholders are anyone who (or whose organisation) has a legal obligation under the IT Act and its Rules to:• Secure sensitive personal data. • Because such person or entity collects, processes, transmits, transfers, stores or deals with sensitive

personal data.

Accountability for SPDI is with the governing body, which could be the chairman, board of directors, owner, proprietor, partner, head of an association or head of an institute.

Responsibility to implement the directives of the governing body rests with management and the executives, as designated by the owners.

External stakeholders These are the shareholders, business partners, suppliers, regulators/government, external users, customers, external auditors, etc.

Internal stakeholders These are the members of:• Governing body—Board, CEO• Management committee—CEO, CFO, CIO, CISO, CPO, CRO, CHRO, CLO and all the C-level executives of

the organisation • Operation and execution team—Business process owners, human resources manager, security officer,

internal auditors, privacy officer, IT users, etc.

Note: These functional designations are just for example. Not every organisation will have all these designations. However, the individual functions will be present and will be the responsibility of one or more individuals.

What is the goal of the organisation structure?

To ensure protection of SPDI in compliance with the IT Act, amended in 2008

What is the governance and management framework?

The governance objective for handling SPDI is risk optimisation. The owners and stakeholders are primarily concerned with the following four enterprise goals:• Enterprise goal 4: Compliance with external law and regulations • Enterprise goal 7: Business service continuity and availability • Enterprise goal 9: Information-based strategic decision making • Enterprise goal 15: Compliance with internal policies

The governance and management framework should have the following three levels, which are representative of the accountability and responsibility. Designations are only indicative. Many small organisations may not have all the designations or positions or may have one person handling more than one function. • Governing body • Management committee• Operation and execution team

Governing body Members: Board, CEO

Accountable to: Owners and external stakeholders

Accountable for: • Setting direction for protection of SPDI• Issuing the privacy policy• Monitoring any breaches of the policy• Reviewing the privacy policy once a year or when any amendment or new legislation is announced

46


EXPOSUREDRAFT

What is the governance and management framework? (cont.)

Management committee Members: Management—CEO, CFO, CIO, CISO, CPO, CRO, CHRO, CLO and all other C-level executives of the organisation

Accountable to: Governing body

Responsible for: • Creation of the privacy policy• Creation and issuance of the information security policy• Identifying, assessing and managing privacy risk on an ongoing basis• Monitoring privacy-related incidences and reporting to the board

Operation and execution team Members: Business process owners, human resources manager, security officer, internal auditors, privacy officer, grievance officer, IT users, etc.

Accountable to: Management

Responsible for:• Establishment of detailed procedures for implementing the privacy policy• Establishment of detailed procedures for implementing the information security policy• Implementation of the privacy policy• Implementation of the information security policy• Regular reporting to management


47

EXPOSUREDRAFT

Life cycle and good practices • Governing body, comprising the board and headed by the chairman – The governing body is at the apex of the organisation structure and is formed as per the applicable

statute or regulations. SPDI is one of the many responsibilities carried by this body. Good enterprise governance practices are mandatory for the existence of the organisation.

– Good practices: . The board should meet at the agreed frequency as per the normal practice. The meeting may be held

for normal business transactions where one of the agenda items is to review the status of protection of SPDI.

. The board should be aware that it is ultimately responsible for the governance of the enterprise and, as such, is fully accountable to meet the provisions of the IT Act, 2000, amended in 2008, and the IT Rules, 2011, and may be subject to claims for substantial compensation.

. The board should issue [or approve] the privacy policy, spelling out the overall intention and direction of the organisation.

. The board should monitor performance, compliance and progress against the agreed-on direction and objectives.

• Management committee, comprising the CEO, CFO, CIO, CISO, CPO, CRO, CHRO, CLO and all the C-level executives of the organisation

– The management committee has the executive powers assigned by the board. and is responsible for carrying out the board’s instructions. Securing SPDI is one of the critical requirements the management committee has to fulfill as the consequences of failure are quite severe.

– Good practices: . Management plans, builds, runs and monitors activities in alignment with the direction set by the

governing body to achieve enterprise objectives. . Management is responsible for formulating the privacy policy for SPDI as well as information security

policy for SPDI, which provides detailed instruction on all aspects of securing the personal and sensitive data or information.

. The management committee should meet at least once a year to review the effectiveness of the privacy and security policies, any privacy breaches, and the actions taken to prevent future occurrences.

. The management committee should provide adequate resources to the operations and execution committee.

. The committee should be headed by CEO or his designate, that should report the progress to the board.• Operation and execution team, comprising business process owners, human resources manager, security

officer, internal auditors, privacy officer, grievance officer, IT users, etc. – The operation and execution team implements policies. As such, it is expected to define detailed

procedures and have adequate resources to carry out the work. – Good practices: . This team is responsible for implementing the privacy and information security policies. As such, it is

responsible for documenting detailed procedures for implementing various measures to secure SPDI. . The team, in turn, may delegate tasks to various groups with specific responsibilities, whose activities

will be closely monitored by the team. . The team should meet at least once every six months to review the status of the implementation. . The operation and execution team’s responsibility should be held by the CISO, assisted by the CPO/

grievance officer. . The CISO should report progress to the management committee.

48


EXPOSUREDRAFT

COBIT 5 Enabler 4: Culture, Ethics and Behaviour

This section, which is adopted from COBIT 5 for Information Security, provides details on information security behaviours.

Eight desirable information security behaviours can be identified that will positively influence culture towards information security and its actual implementation in the enterprise’s day-to-day life. For each of the behaviours defined, the following attributes are described in this section:• Organisational ethics—Determined by the values by which the enterprise wants to live• Individual ethics—Determined by the personal values of each individual in the enterprise, and to an important extent are

dependent on external factors such as beliefs, ethnicity, socio-economic background, geographic location and personal experiences

• Leadership—Ways leadership can influence appropriate behaviour: – How communication, enforcement, and rules and norms can be used to influence behaviour – The incentives and rewards that can be used to influence behaviour – Raising awareness

BehavioursEach of the following behaviours occurs in an enterprise at two levels: the organisational level, where behaviours are determined by the values (ethics, culture or attitude) by which the enterprise wants to live, and the individual level, where behaviours are defined by the personal values (ethics, culture or attitude) of the individual.• Behaviour 1: Information security is practiced in daily operations.

Information security is part of the enterprise’s daily functioning. At the organisational level, the behaviour indicates that information security is accepted as a business imperative in organisational goal setting. At the individual level, it means that the individual cares about the well-being of the enterprise and applies a prudent approach and information security techniques to his/her daily operations.

• Behaviour 2: People respect the importance of information security policies and principles. The importance of information security policies and principles is acknowledged by the people in the enterprise. At the organisational level, policies and principles are endorsed by senior management, and approval, review and communication of policies occurs on a regular basis. At the individual level, people have read and understood the policies, and they feel empowered to follow enterprise guidance.

• Behaviour 3: People are provided with sufficient and detailed information security guidance and are encouraged to participate in and challenge the current information security situation. People are provided with sufficient information security guidance and are encouraged to challenge the current information security situation at two levels. The organisational culture indicates a two-way communication process for guidance and feedback and provides stakeholders an opportunity to comment on changes; the individual culture demonstrates stakeholder participation by questioning and providing comments when requested.

• Behaviour 4: Everyone is accountable for the protection of information within the enterprise. This accountability is reflected at two levels in the enterprise. At the organisational level, issues requiring accountability (discipline) are acted upon and the roles of stakeholders are confirmed for enforcement. The individual level requires each individual to understand the responsibilities regarding information security.

• Behaviour 5: Stakeholders are aware of how to identify and respond to threats to the enterprise. Appropriate processes for identifying and reacting to threats can be implemented at the organisational level by installing a reporting process and an incident response process to minimise losses. At the individual level, people must be educated on what an information security incident is and how to report and react to it.

• Behaviour 6: Management proactively supports and anticipates new information security innovations and communicates this to the enterprise. The enterprise is receptive to accounting for and dealing with new information security challenges. Information security innovations and challenges are tackled at the organisational level through an information security research and development team. The individual culture contributes when stakeholders bring new ideas forward.

• Behaviour 7: Business management engages in continuous cross-functional collaboration to allow for efficient and effective information security programmes. Cross-functional collaboration is leveraged in the enterprise by organisational acceptance of a holistic information security strategy and improved integration with the business. The individual contributes by reaching out to other business functions and by identifying potential synergies.

• Behaviour 8: Executive management recognises the business value of information security. The business value of information security is recognised at the organisational level when information security is viewed as a means to improve business value (revenue, expense, reputation and competitive advantage), transparency in response to incidents is key, and an understanding of consumer expectations is essential. At the individual level, the behaviour is evidenced by the generation of creative ideas to improve value (various layers of information security).


49

EXPOSUREDRAFT

LeadershipThe behaviours described can be influenced by leadership at different levels of the enterprise. Three levels of leadership can be distinguished: information security management (CISO/ISM) at the information security level, business management at the business unit level, and executive management at the top level.

These layers of leadership influence behaviour through the use of communication, enforcement and rules, incentives and rewards, and awareness.• Influencing behaviour through communication, enforcement, and rules and norms

Leadership uses communication, enforcement, and rules and norms to influence behaviours in an enterprise. Communication is always essential to influence any kind of behaviour. Enforcement of an information security culture is dependent on the degree of importance of that aspect of a culture. Rules can be used to force internal action where information security is legally mandated. Information security management (CISO/ISM) makes sure that information security is embedded in enterprise policies and procedures, and regular guidance and updates are performed. Furthermore, the CISO/ISM ensures a yearly recertification of policies and principles. Together with executive management, the CISO/ISM ensures a formal sign-off of these policies. Business unit managers follow up on corrective actions and executive management performs an annual review of information security performance. The CISO/ISM works together with business unit management to ensure stakeholder acknowledgement. The business unit managers also set an example by leading. The CISO/ISM implements an incident management process, supported by a reporting mechanism, which includes trigger points for stakeholders (clients, vendors, etc.). Market trends are tracked by the CISO/ISM as well, for both information security and the business. While executive management ensures that information security is represented in the correct structures (committees, task forces, implementation teams), the CISO/ISM communicates the information security processes to the entire enterprise.

• Influencing behaviour through incentives and rewards Management influences behaviour through measures designed to provide positive reinforcement for desired conduct and negative reinforcement for conduct it wishes to discourage. An absence of rewards inhibits adoption of an information security culture. Business management needs to know that secure behaviour will be rewarded; this, in turn, means that executive management must make its intentions clear by encouraging the implementation of security safeguards and promoting attitudes that constitute a culture of security. These rewards do not involve money that goes directly to the individual; instead, they may constitute organisational advancement in the form of budget, influence, management attention, etc. Some people are motivated solely by remuneration, others also appreciate other types of recognition. The following incentives and rewards may be used by the various management levels to influence behaviour:

– Information security management (CISO/ISM) may organise sessions regarding information security in personal life (e.g., covering children and social media, wireless network setup) to embed information security in daily operations, give positive recognition for the information security achievement, and distribute bonuses for innovation within the information security function. The CISO/ISM is not the only level of management to give bonuses; executive management may also give rewards for alerting of threats or for any profitable idea.

– Business management focusses on information security as a component of performance evaluation and ensures that it is embedded in all job descriptions, while executive management tailors incentives and rewards to the responsibility of the stakeholders. Business management is responsible for an annual review of the incentives and rewards programme and adheres to the fact that information security policies are a requirement of employment (terms and conditions).

• Influencing behaviour through raising awareness Awareness programmes have their place, but they are insufficient by themselves. More than just being aware of information security, people need to be educated about security and their role in it. The different management levels in an enterprise can raise awareness through the following means:

– Information security management may organise awareness training on information security topics, supported by regular update sessions, and ensure that policies are readily available (e.g., through Internet publication). The CISO/ISM is also responsible for sharing knowledge regarding changes in the threat landscape, regularly communicating new ideas and outcomes, keeping track of market trends, and performing competitive analyses. Business managers regularly follow these awareness training events and are responsible for notifications or requests for comments on proposed changes.

– Executive management makes sure that information security incidents are communicated to the staff.

50


EXPOSUREDRAFT

COBIT 5 Enabler 5: Information

The information enabler deals with all information relevant for enterprises, not only automated information. Information can be structured or unstructured, formalised or informalised.

Information can be considered as one stage in the ‘information cycle’ of an enterprise. In the information cycle (figure 11), business processes generate and process data, transforming them into information and knowledge, and ultimately generating value for the enterprise. The scope of the information enabler mainly concerns the ‘information’ phase in the information cycle, but the aspects of data and knowledge are also covered in COBIT 5.

Figure 11—COBIT 5 Information Cycle

Information cycle for SPDI Personal information and SPDI are collected, stored and processed by many organisations as a part of their normal work. Since the SPDI could be misused inadvertently or otherwise, the IT Act, amended in 2008, and IT Rules, 2011, have stipulated that measures be taken to secure the data or information. This is explained in the remainder of this table, starting with the stakeholders of SPDI and then various quality goals for SPDI that need to be achieved to secure the SPDI.

Stakeholders The four categories of stakeholders and their specific activities with regard to the SPDI resources follow. Details of activities performed will depend on the life cycle phase of the information.• SPDI owners—The individuals whose personal information is collected, stored and processed. They

are the major stakeholders. The organisation’s privacy policy assures the SPDI owners of the security surrounding the sensitive personal information collected from them.

• SPDI custodians—Responsible for storing and maintaining the SPDI. These internal stakeholders are concerned with the policy, procedures and activities to be followed to ensure adequate security of the sensitive personal information so that there is no breach of privacy resulting in legal action and/or loss of reputation.

• SPDI consumers—Responsible for using the information. They could be internal or external stakeholders who need to provide some service based on the SPDI.

• SPDI guardians—External stakeholders (such as regulatory bodies) who are concerned with adequacy of the steps taken to protect the SPDI and full compliance with the law

Goal—Intrinsic Quality • Accuracy—The SPDI collected by the enterprise should be correct and reliable. For example, the financial or medical records held by the organisation should be accurate. The SPDI collected by the enterprise should be captured and stored accurately. The personal information provider has the right to review the accuracy of SPDI available with the enterprise.

• Consent—Prior consent from the SPDI producer should be obtained for collection and use of the SPDI.• Notice— A notice in simple and clear language should be given prior to collection of SPDI.• Objectivity— The SPDI encompasses items like financial information, medical records and sexual

orientation. This information must be unbiased, unprejudiced and impartial.• Believability— The SPDI must be true and credible. This quality also reflects upon the accuracy and

integrity of the information. Vague, incomplete or inaccurate information impacts credibility. • Reputation— This is the extent to which information is highly regarded in terms of its source or content.

DriveGenerate and Process

Data

Information Knowledge

Business Processes

IT Processes

Value

CreateTransformTransform


51

EXPOSUREDRAFT

Goal—Contextual and representational quality

• Relevancy— SPDI should be collected only for lawful purpose connected with functions or activities of the enterprise and only essential data should be collected for such functions or activities.

• Completeness— This is the extent to which information is not missing and is of sufficient depth and breadth for the task at hand.

• Collection limitation— Collection of the SPDI should be relevant to the identified purpose only.• Use limitation— Use of SPDI should be limited to the stated purpose only.• Integrity— The SPDI should be accurate and free from errors. • Currency— The SPDI must be up to date for the functions or activities where it is used. • Appropriate amount of information— The data collected should be appropriate and adequate for the

intended purpose. • Concise representation— Concise representation of data precludes excessive and irrelevant data that

may obscure what is relevant to the intended purpose.• Consistent representation — Consistent representation, preferably using the same format, allows

comparisons and reviews on a consistent basis, thereby aiding decision making.• Interpretability— Achieving clarity through appropriate languages, symbols and units, with clear

definitions• Understandability—The information should be direct and easily comprehended.• Ease of manipulation— The information should be easy to manipulate and apply to different tasks, but its

integrity should never be compromised.

Goal—Security/accessibility quality • Availability— The SPDI should be available only for the specific purpose for which it was collected.• Timeliness— The SPDI should be available only for the specified period.• Restricted access— The SPDI should be available only to authorised persons for the specified purpose

and duration.• Accountability— A senior person in the organisation should be accountable for the SPDI collected by the

organisation.

Life cycle • Plan—SPDI is usually collected through some input process. This could be paper forms, web-based forms, emails, etc. As per ther IT Act, before the SPDI is collected, there should be some conspicuous notification about the fact that the information is being collected, the purpose for the collection, the name of the agency that is collecting the information, the name of the agency that will retain the information, the duration for which the information will be retained and the option of not providing the information. The information should be collected only after consent is obtained. The SPDI must be collected only for lawful purposes. The information must be stored in a secure manner. The information may be revealed to a government agency only as per the applicable laws.

• Design—The input, processing and output of the SPDI collection process should be appropriately designed to incorporate the requirements identified in the Plan phase. The input may be paper-based or digital. The procedures or privacy and information security policies for SPDI contain the design requirements to which the process should conform.

• Build/acquire—The entire process of acquiring, storing, transferring and using the SPDI should be built with security in mind. The process may be manual or electronic. The procedures for privacy and information security policies for SPDI should be consulted to ensure that the build/acquire phase meets the design criteria. The checklists provided in chapter 1 will also prove helpful.

• Use/operate: – Store—Storage of hard-copy forms in a way to ensure restricted access should be planned. Storage of

digital information is more complex to control as the digital data could be easily copied. The data could be in files, databases, web servers or mail servers and could also be copied on backup media, USB drives or distributed by email. Since the rules do not permit usage of SPDI beyond a permitted time or for any application other than that for which it was collected, it should not be stored beyond the required time limit.

– Share—SPDI can be shared only with other organisations under lawful contract and only when the receiving organisation also provides an equal level of security.

– Use—The use of SPDI must be restricted to only the purpose for which it was collected. – Destroy—The SPDI must be irrevocably destroyed after the expiry of the period for which it was

allowed to be used. For digital information, destruction involves removing data from all the backup media.

52


EXPOSUREDRAFT

Best practices SPDI should be secured at various layers.

Best practices—Physical-world layer Physical-world security requires the SPDI to be secure at three stages:• When at rest: – A paper document containing SPDI should be physically secured in locked cupboards or other containers

with appropriate physical access controls. – Digital documents are stored on media such as disk drives, flash drives, CD/DVD and backup tapes.

These should be physically secured. In addition, it is desirable also to encrypt the SPDI stored on these media.

• When in motion: – Paper documents should be sent only through secure methods. – Digital communication should use encryption such as HTTPS for transferring any SPDI.• When in actual use: – The access for actual use should be restricted to authorised persons. – An audit log should be maintained.

Best practices—Empirical layer The empirical layer encompasses the observation of the signs used to encode information and their distinction from each other and from background noise.

The user interfaces created for capturing SPDI should hide the information. For example, passwords should be masked by **********. Similar masking should be used in all fields capturing other SPDI, such as financial information or medical information. There may be a facility to lift the mask to verify the information but the mask should be a default option. If allowed by technology, the fields capturing SPDI should be encrypted.

Transmission of the SPDI should always use encryption.

If the SPDI is to be used for statistical purposes, anonymizing techniques should be used.

When information is to be used for research, resource planning, and examination of correlations and trends, it should be de-identified by removing or obscuring sensitive personal information.

Best practices—Syntactic layer The syntactic layer refers to the rules and principles for constructing sentences in natural or artificial languages. In this case, syntax specifically refers to the form of information.

Wherever possible, structured languages like XML should be used to convey the SPDI in a secure manner using XML encryption.

Best practices—Semantic layer The semantic layer pertains to the rules and principles for constructing meaning out of syntactic structures. In this case, semantics refers to the meaning of information and encompasses:• Information type—This attribute identifies the kind of information, e.g., financial vs. non-financial

information or internal vs. external origin of the information. It is helpful to create SPDI as a distinct information type to provide a higher level of security.

• Information currency—An indicator should be built to display the currency of SPDI.• Information level—The degree of level should be restricted to the requirement of the activity or function

for which the SPDI is collected, using the minimum information required by the activity or the person whose information is being displayed.

Best practices—Pragmatic layer The following four attributes are required for managing SPDI and should be built into the information system:• Retention period—The attribute that identifies how long SPDI can be retained before it is destroyed.• SPDI status—The attribute that identifies whether the SPDI is operational or historical.• Novelty—The attribute that identifies whether the SPDI creates new knowledge or confirms existing

knowledge, i.e., information vs. confirmation.• Contingency—The attribute that identifies the information that is required to precede this information (for

it to be considered information).

Best practices—Social-world layer Some information, e.g., sexual orientation, medical conditions (such as HIV) or status as an ex-convict, may be inappropriate or undesirable to be displayed in some cultures.An attribute should be built in that identifies this context, e.g., cultural context or subject domain context.


53

EXPOSUREDRAFT

COBIT 5 Enabler 6: Services, Infrastructure and Applications

Securing sensitive personal information may require special focus on creating the services capabilities (a combined term for services, architecture and applications) to meet the promises made to the customers through the privacy policy.

Stakeholders • Internal stakeholders: Internal IT departments, operations manager, outsourcing providers, internal business users

• External stakeholders: Customers, external business users, partners, clients, suppliers, regulators and external auditors

Goals Handling of SPDI should be done in an efficient and secure manner through deployment of various services leading to reliable and trustworthy business processes.

Life cycle The services may be provided by an in-house team or may be outsourced. The infrastructure may be owned by the organisation or may belong to a third party. Similarly, applications may be developed in-house or may be off the shelf. They may even be cloud-based services, i.e., IaaS, PaaS or SaaS.

While planning, designing, building/acquiring, using/operating or terminating these services, the accountability for SPDI always remains with the organisation. Therefore, careful analysis of the roles and responsibilities should be done. Proper evaluations should be carried out and effective monitoring and reporting should be established to track any privacy breach. An effective incident management process is necessary to help the organisation prevent, detect and correct any lapses in securing the SPDI.

Good practices Emphasis in the architecture design should be on security of SPDI. This becomes very important if outsourcing of services is used or cloud-based services are planned.

The service level agreements should clarify the legal responsibilities of the service provider regarding SPDI.

Confidentiality agreements should ensure that confidentiality of information is maintained, as required by the IT Act.

Potential SPDI-related services • Offer SPDI security awareness training• Develop applications for SPDI security• Provide user access and access rights in line with business requirements• Establish adequate protection against malware, external attacks and intrusion attempts• Ensure adequate incidence response• Secure legal services for SPDI• Provide SPDI audit services• Provide security and alert services for SPDI security-related events• Offer grievance redressal services

54


EXPOSUREDRAFT

COBIT 5 Enabler 7: People, Skills and Competencies

Securing SPDI is a relatively new concept in India. It will require sustained effort by organisations to internalise it and make it part of business practice.

Stakeholders • External stakeholders: Personal information providers, customers Those who provide personal information should be well aware of their rights and responsibilities. The policy should be written in a simple manner to educate them on the measures taken by the enterprise to protect their SPDI and also their option not to provide this information, or opt out.

• Internal stakeholders: – Board and Chairman—These stakeholders need proper education to ensure that they clearly

understand their accountability for SPDI and possible legal repercussions. – Management—The responsibility for securing SPDI, implementing the privacy and security policies,

and taking timely action against any breaches is expected to be thoroughly understood by these stakeholders. As a result of proper education, they should also understand the risk of not complying with the law.

– Operation and the execution team—These are the people at ground level, actually implementing the policies. They should be well trained on the practical aspects of securing the SPDI through managerial, technical and physical measures. They need to be trained on requisite skills to carry out their responsibilities.

– General staff—These stakeholders need to carry out day-to-day functions without compromising the privacy policy of the organisation. This is the weakest link, so the majority of the awareness-raising efforts should be invested in improving their understanding and ensuring that they implement the policies without resorting to shortcuts. Adequate training in this area is a necessity.

Goal To provide stakeholders appropriate education, skills and training to successfully secure the SPDI

Life cycle Education, skill building and training should be part of an annual calendar and all stakeholders should be exposed to it. Some stakeholders may require specific skills; additional skill-building workshops should be arranged for them. For example, areas like incident management, risk management, and implementation of technical and physical controls for protection of SPDI may require additional skill-building efforts. Software developers may need to be trained on developing secure software.

Good practices Figure 39 in COBIT 5 lists some examples of skill categories. The relevant skill categories for securing SPDI are:

Process Domain Examples of Skill CategoriesStakeholders Who Would Benefit From These Skills

Evaluate, Direct and Monitor (EDM)

• Governance of enterprise IT with emphasis on SPDI

Board and chairman, management committee

Deliver, Service and Support (DSS) • Service desk and incident management

Operation and the execution team

• Security administration

Monitor, Evaluate and Assess (MEA)

• Compliance review Management committee

• Control audit

Appropriate educational seminars should be designed for the board and management and delivered at least once a year. Adequate examples should be given to drive home the point of accountability.

Ensure that the right skills are imparted to the operation and execution team to enable it to take responsibility for securing SPDI. The team should be well trained on various procedures identified for privacy as well as security of SPDI.


55

EXPOSUREDRAFT

Conclusion

This publication has explained an approach to using COBIT 5 for securing (SPDI as required by the Indian IT Act requirement.

Chapter 1 explained Indian laws and regulations regarding the protection of SPDI and provided checklists to help in conforming to the requirements of the IT Act.

Chapter 2 addressed how to use COBIT 5 to secure SPDI. The executive summary of COBIT 5 presented the background about COBIT 5. This was then expanded and the linkage to securing SPDI using COBIT 5 was created.

Chapter 3 described how stakeholders’ needs are met for securing SPDI. First, the stakeholders for SPDI were identified, and then the goals cascade was used to link stakeholders’ needs for securing SPDI to enterprise goals, IT related goals and enabler goals.

Chapter 4 explained the COBIT 5 enablers for securing SPDI, elaborating on each of the seven enablers to address all possible aspects of securing SPDI and provide reasonable security practices and procedures.

The next step in the effort to secure SPDI is to use COBIT 5 Implementation. That publication approaches the systematical implementation and achievement of the goal of securing SPDI in the enterprise by applying a continual improvement life cycle process.

In COBIT 5 Implementation, the emphasis is on the enterprise wide view of the governance of IT. This guide and COBIT 5 recognise that information and the related information technologies are pervasive in the enterprises and that it is neither possible nor good practice to separate the business and the IT-related activities. The governance and management of enterprise IT should therefore be implemented as an integral part of enterprise governance, covering the full end-to-end business and IT functional areas of responsibility.

COBIT 5 is freely downloadable from www.isaca.org/cobit. A link to the ISACA products available to support implementation is available on this page as well.

56

EXPOSUREDRAFT

securIng sensItIve PersonAl dAtA or InformAtIon: usIng cobIt® 5 for IndIA’s It Act

Annexures

Annexure A—Glossary of Terms

TERM DEFINITION

Accountable party (RACI) The individual, group or entity that is ultimately responsible for a subject matter, process or scope

In a RACI chart, answers the question: Who accounts for the success of the task?

Accountability of governance

Governance ensures that enterprise objectives are achieved by evaluating stakeholder needs, conditions and options; setting direction through prioritisation and decision making; and monitoring performance, compliance and progress against plans. In most enterprises, governance is the responsibility of the board of directors, under the leadership of the chairperson.

Activity In COBIT, the main action taken to operate the process. Guidance to achieve management practices for successful governance and management of enterprise IT. Activities:• Describe a set of necessary and sufficient action-oriented implementation steps to achieve a

Governance Practice or Management Practice• Consider the inputs and outputs of the process• Are based on generally accepted standards and good practices• Support establishment of clear roles and responsibilities• Are non-prescriptive and need to be adapted and developed into specific procedures appropriate

for the enterprise

Alignment A state where the enablers of governance and management of enterprise IT support the goals and strategies of the enterprise

Authentication The act of verifying the identity of a user and the user’s eligibility to access computerised informationScope Note: Assurance: Authentication is designed to protect against fraudulent logon activity. It can also refer to the verification of the correctness of a piece of data.

Body corporate Any company and includes:• A firm (such as a partnership firm)• Sole proprietorship (such as a consultancy firm owned by a single person)• Other association of individuals (such as professional bodies and organisations) engaged in commercial or professional activities

Business continuity Preventing, mitigating and recovering from disruption. The terms ‘business resumption planning’, ‘disaster recovery planning’ and ‘contingency planning’ also may be used in this context; they focus on recovery aspects of continuity, and for that reason the ‘resilience’ aspect should also be taken into account.

Business goal The translation of the enterprise’s mission from a statement of intention into performance targets and results

Business process control The policies, procedures, practices and organisational structures designed to provide reasonable assurance that a business process will achieve its objectives

Annexures

Annexures

57

EXPOSUREDRAFT

TERM DEFINITION

COBIT 5 Formerly known as Control Objectives for Information and related Technology (COBIT); now used only as the acronym in its fifth iteration. A complete, internationally accepted framework for governing and managing enterprise information and technology (IT) that supports enterprise executives and management in their definition and achievement of business goals and related IT goals. COBIT describes five principles and seven enablers that support enterprises in the development, implementation, and continuous improvement and monitoring of good IT-related governance and management practices.

Scope Note: Earlier versions of COBIT focused on control objectives related to IT processes, management and control of IT processes and IT governance aspects. Adoption and use of theCOBIT framework are supported by guidance from a growing family of supporting products.(See www.isaca.org/cobit for more information.)

Code of ethics A document designed to influence individual and organisational behaviour of employees by defining organisational values and the rules to be applied in certain situations. It is adopted to assist those in the enterprise called upon to make decisions understand the difference between ‘right’ and ‘wrong’ and to apply this understanding to their decisions.

Context The overall set of internal and external factors that might influence or determine how an enterprise, entity, process or individual acts

Scope Note: Context includes:• Technology context—Technological factors that affect an organisation’s ability to extract value

from data• Data context—Data accuracy, availability, currency and quality• Skills and knowledge—General experience, and analytical, technical and business skills• Organisational and cultural context—Political factors, and whether the organisation prefers data

to intuition• Strategic context—Strategic objectives of the enterprise

Control The means of managing risk, including policies, procedures, guidelines, practices or organisational structures, which can be of an administrative, technical, management or legal nature. Also used as a synonym for safeguard or countermeasure.

C suite executives CEO—Chief Executive OfficerCFO—Chief Finance OfficerCIO—Chief Information OfficerCISO—Chief Information Security OfficerCPO—Chief Privacy OfficerCRO—Chief Risk OfficerCHRO—Chief Human Resources OfficerCLO—Chief Legal Officer

Culture A pattern of behaviours, beliefs, assumptions, attitudes and ways of doing things

Enterprise goal See Business goal

Enterprise governance A set of responsibilities and practices exercised by the board and executive management with the goal of providing strategic direction, ensuring that objectives are achieved, ascertaining that risk is managed appropriately and verifying that the enterprise’s resources are used responsibly. It could also mean a governance view focussing on the overall enterprise; the highest-level view of governance to which all others must align.

Good practice A proven activity or process that has been successfully used by multiple enterprises and has been shown to produce reliable results

Governance Governance ensures that stakeholder needs, conditions and options are evaluated to determine balanced, agreed-on enterprise objectives to be achieved; setting direction through prioritisation and decision making; and monitoring performance and compliance against agreed-on direction and objectives.

58


EXPOSUREDRAFT

TERM DEFINITION

Governance/management practice

For each COBIT process, the governance and management practices provide a complete set of high-level requirements for effective and practical governance and management of enterprise IT. They are statements of actions from governance bodies and management.

Information An asset that, like other important business assets, is essential to an enterprise’s business. It can exist in many forms: printed or written on paper, stored electronically, transmitted by post or electronically, shown on films, or spoken in conversation.

Inputs and outputs The process work products/artefacts considered necessary to support operation of the process. They enable key decisions, provide a record and audit trail of process activities, and enable follow-up in the event of an incident. They are defined at the key management practice level, may include some work products used only within the process and are often essential inputs to other processes. The illustrative COBIT 5 inputs and outputs should not be regarded as an exhaustive list since additional information flows could be defined depending on a particular enterprise’s environment and process framework.

IT application Electronic functionality that constitutes parts of business processes undertaken by, or with the assistance of, IT

IT goal A statement describing a desired outcome of enterprise IT in support of enterprise goals. An outcome can be an artefact, a significant change of a state or a significant capability improvement.

IT service The day-to-day provision to customers of IT infrastructure and applications and support for their use. Examples include service desk, equipment supply and moves, and security authorisations.

Lawful Purpose (as per the IT Act –for the collection of SPDI)

A lawful purpose is a purpose:• Connected with a function or activity of the body corporate or any person on its behalf• For which the collection of the sensitive personal data or information is considered necessary

Management Management plans, builds, runs and monitors activities in alignment with the direction set by the governance body to achieve the enterprise objectives.

Metric A quantifiable entity that allows the measurement of the achievement of a process goal. Metrics should be SMART—specific, measurable, actionable, relevant and timely. Complete metric guidance defines the unit used, measurement frequency, ideal target value (if appropriate) and also the procedure to carry out the measurement and the procedure for the interpretation of the assessment.

Organisational structure An enabler of governance and of management. Includes the enterprise and its structures, hierarchies and dependencies.

Example: Steering committee

Output See Inputs and outputs

Owner Individual or group that holds or possesses the rights of and the responsibilities for an enterprise, entity or asset, e.g., process owner, system owner

Personal information (PI), (as per the I T Act)

Any information that relates to a natural person, which, either directly or indirectly, in combination with other information available or likely to be available with a body corporate, is capable of identifying such person.

Process Generally, a collection of practices influenced by the enterprise’s policies and procedures that takes inputs from a number of sources (including other processes), manipulates the inputs and produces outputs (e.g., products, services)

Scope note: Processes have clear business reasons for existing, accountable owners, clear roles and responsibilities around the execution of the process, and the means to measure performance.

Process goal A statement describing the desired outcome of a process. An outcome can be an artefact, a significant change of a state or a significant capability improvement of other processes.

Quality Being fit for purpose (achieving intended value)

Annexures

59

EXPOSUREDRAFT

TERM DEFINITION

Reasonable security practices and procedures

Security practices and procedures designed to protect information from unauthorised access, damage, use, modification, disclosure or impairment:• As may be specified in an agreement between the parties• As may be specified in any law for the time being in force• And in the absence of such agreement or any law, such reasonable security practices and

procedures, as may be prescribed by the Central Government in consultation with such professional bodies or associations as it may deem fit

Risk The combination of the probability of an event and its consequence (ISO/IEC 73)

Risk management One of the governance objectives. Entails recognising risk; assessing the impact and likelihood of that risk; and developing strategies, such as avoiding the risk, reducing the negative effect of the risk and/or transferring the risk, to manage it within the context of the enterprise’s risk appetite.

Services See IT service

Skill The learned capacity to achieve predetermined results

SPDI —Sensitive Personal Data or Information (as per the IT Act)

Such personal information that consists of information relating to:• Password• Financial information such as bank account, credit card, debit card or other payment instrument

details• Physical, physiological and mental health condition• Sexual orientation• Medical records and history• Biometric information

Stakeholder Anyone who has a responsibility for, an expectation from or some other interest in the enterprise—e.g., shareholders, users, government, suppliers, customers and the public

Annexure B—List of Figures

Figure 1—COBIT 5 Principles ................................................................................................................................................18Figure 2—COBIT 5 Goals Cascade Overview .......................................................................................................................21Figure 3—Key Roles, Activities and Relationships ................................................................................................................22Figure 4—Mapping COBIT 5 Enterprise Goals to Governance and Management Questions ........................................ 23-24Figure 5—Mapping COBIT 5 Enterprise Goals to Governance Objective ............................................................................25Figure 6—Mapping COBIT 5 Enterprise Goals to IT-related Goals ......................................................................................26Figure 7—Summary of the Selected IT-related Goals.............................................................................................................27Figure 8—COBIT 5 Enterprise Enablers ................................................................................................................................28Figure 9—COBIT 5 Illustrative Governance and Management Processes.............................................................................41Figure 10—Mapping COBIT 5 IT-related Goals to Processes .......................................................................................... 42-43Figure 11—COBIT 5 Information Cycle ................................................................................................................................50

60


EXPOSUREDRAFT

Annexure C—List of Policies and Procedures

Policies and Procedures Required for Securing SPDI

1. Privacy Policy for SPDI

2. Procedures for Privacy Policy2.1 Procedure for identifying SPDI2.2 Procedure for identifying business processes using SPDI2.3 Procedure for obtaining consent2.4 Procedure for allowing access to SPDI for review by the provider2.5 Grievances redressal procedure2.6 Procedure for providing access to the Government agencies2.7 Procedure for transferring / sharing data with 3rd parties2.8 Procedure for penalties for any breaches by internal or external entities handling SPDI2.9 Procedure for meeting intrinsic quality goals for SPDI2.10 Procedure for meeting contextual and representational quality goals for SPDI2.11 Confidentiality Agreement for outsourcing or insourcing of services for SPDI

3. SPDI Security Management Policies3.1 SPDI security policy3.2 Ethics policy for SPDI3.3 Risk management policy3.4 SPDI incidence response policy3.5 SPDI security safeguards review policy3.6 Compliance policy for SPDI with IT Act3.7 Outsourcing and Insourcing policy for SPDI

4. SPDI Security Procedures4.1 Risk management procedure4.2 Procedure for collection, classification and analysis of SPDI related risks4.3 Procedure for estimating business impact for SPDI related risks4.4 Procedure to identify scope, boundary of the SPDI security management system4.5 Procedure for SPDI incident response4.6 Procedure for protection against malware4.7 Procedure for managing network and connectivity security4.8 Procedure for managing endpoint security4.9 Procedure for managing user identity and logical access, to ensure security/accessibility of SPDI4.10 Procedure for managing physical access to SPDI assets4.11 Procedure for managing sensitive documents and output devices4.12 Procedure for monitoring the infrastructure for security-related events4.13 Procedure for reviewing the SPDI security controls and safeguards4.14 Procedures for reviewing the SPDI controls and safeguards with IT Act requirements4.15 Procedure for secure storage of SPDI4.16 Procedure for destruction/disposal of SPDI4.17 Procedure for secure transmission of SPDI4.18 Procedure for maintaining audit log for access to SPDI4.19 Procedure for maintaining security at the empirical layer for SPDI4.20 Procedure for maintaining security at the syntactic layer for SPDI4.21 Procedure for maintaining security at the semantic layer for SPDI4.22 Procedure for maintaining security at the pragmatic layer for SPDI4.23 Procedure for maintaining security at the social world layer4.24 Service Level Agreement for outsourcing or insourcing of services for SPDI4.25 SPDI Training programs for all levels in the organisation

Annexures

61

EXPOSUREDRAFT

Annexure D—References

1 The Information Technology Act, 2000, www.mit.gov.in/sites/upload_files/dit/files/downloads/itact2000/itbill2000.pdf2 The Information Technology (Amendment) Act, 2008, www.mit.gov.in/sites/upload_files/dit/files/downloads/itact2000/it_amendment_act2008.pdf

3 Notifications from Ministry of IT, www.mit.gov.in/content/notifications4 COBIT 5, www.isaca.org/cobit5 COBIT 5: Enabling Processes, www.isaca.org/cobit/Documents/COBIT-5-Enabling-Processes-Introduction.pdf6 COBIT 5 Implementation, www.isaca.org/cobit/Documents/COBIT-5-Implementation-Introduction.pdf7 COBIT 5 for Information Security, www.isaca.org/COBIT/Pages/info-sec.aspx8 ISO/IEC 27001:2005, Information technology—Security techniques—Information security management

systems—Requirements9 Fair Information Practices from OECD Guidelines governing the protection of privacy and transborder flow of personal

data, www.oecd.org

Annexure E—FAQ’sFor comments, discussion and frequently asked questions, please refer to www.isaca.org/topic-india