10 1 1 252 9782

Securing Sensitive Personal
Data or Information
Under Indias IT Act
Using COBIT 5
Issued by
ISACAs India Task Force
Based on:
Securing Sensitive Personal Data or Information

Under Indias IT Act Using COBIT 5
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 non-profit, 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 fulfil their IT governance and management responsibilities,
particularly in the areas of assurance, security, risk and control, and deliver value to the business.
Disclaimer
This 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 Under Indias IT Act Using
COBIT 5 are solely those of the authors of this publication as a practical application and implementation of COBIT 5
principles and good 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 non-commercial use and for consulting/advisory engagements,
and must include full attribution of the materials 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, 2012. All rights reserved.
ISACA, COBIT 5 for Information Security, 2012. All rights reserved.
ISACA
3701 Algonquin Road, Suite 1010
Rolling Meadows, IL 60008 USA
Phone: +1.847.253.1545
Fax: +1.847.253.1443
Email: info@isaca.org
Web site: www.isaca.org
ISACA and COBIT are registered trademarks of ISACA.
Participate in the ISACA Knowledge Center: www.isaca.org/topic-India
Follow ISACA on Twitter: https://twitter.com/ISACANews
Join ISACA on LinkedIn: ISACA (Official), http://linkd.in/ISACAOfficial
Like ISACA on Facebook: www.facebook.com/ISACAHQ
Securing Sensitive Personal Data or Information Under Indias IT Act Using COBIT 5
2
Acknowledgements
Acknowledgements
ISACA wishes to recognise:
The ISACA India Growth Task Force
Chairman, Niraj Kapasi, CISA, Kapasi Bangad Tech Consulting Pvt, Ltd., Hyderabad, India
Sanjay Bahl, CISM, New Delhi, India
Madhav C. Chablani, CISA, CISM, TippingEdge Consulting Pvt. Ltd, New Delhi, India
Sandeep Narayan Godbole, CISA, CISM, CGEIT, Syntel, Pune, India
Balakrishnan Natarajan, CISA, CISM, Target Corporation, Bangalore, India
Vittal Raj, CISA, CISM, CGEIT, Kumar and Raj, Chennai, India
Raghavendra Rao Hulgeri, CISA, Oracle Financial Services Software Ltd., Bangalore, India
S.V. Sunder Krishnan, CISA, Reliance Life Insurance Company Ltd., Mumbai, India
Additional Expert Reviewers:
Abdul Rafeq, CISA, CGEIT, CIA, FCA, A Rafeq and Associates, Bangalore, India
Vidya Sagar Chemudupati, CISA, CRISC, CRMA, Australian Government, Canberra, Australia
MSV Rao, CISA, Hyderabad, India
Bharat Mehta, VP, Cap Gemini India, and Founding Member of the Technology Law Forum, Mumbai, India
N.S. Nappinai, Advocate, High Court, Mumbai and Chennai, and Founding Member of theTechnology Law Forum, India
Adv. Sagar Rahurkar, LL.M. CCI, CFE - Techno-Legal and Fraud Control Consultant, Pune, India
Rajan R. Vaswani, CISA, CISM, CGEIT, CISSP, MBCI, IBM India Pvt. Ltd., Mumbai, India

Authors
Avinash W. Kadam, CISA, CISM, CGEIT, CRISC
Advisor, ISACAs 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 as the head of IT departments 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 ISACAs 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 ISACAs Mumbai Chapter
from 1998 to 2000. He was the recipient of ISACAs Harold Weiss Award in 2005, given to recognise dedication to the IS
audit, control and security profession.
Subramaniam Vutha, B.Com, LLM, ACS, DTM

Advocate
Subramaniam Vutha is the former senior vice president, legal, of Tata Infotech Ltd. and of Schoolnet India Ltd. 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 (LES), India. 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 Internationals earlier publication titled World Internet Law Report.
Vutha acts as a lecturer on IT law at the University of Mumbais 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.
Table of Contents
Table of Contents
Preface........................................................................................................................................................................................6
Chapter 1. What Is Personal Information?............................................................................................................................9
Chapter 2. Indian Sensitive Personal Data or Information (SPDI) Protection Regulations..........................................13
Chapter 3. How COBIT 5 Can Be Used to Secure SPDI....................................................................................................25
Chapter 4. Meeting Stakeholders Needs for Securing SPDI.............................................................................................29
Chapter 5. COBIT 5 Enablers for Securing SPDI..............................................................................................................37
COBIT 5 Enabler 1: Principles, Policies and Frameworks.................................................................................................39
COBIT 5 Enabler 2: Processes............................................................................................................................................50
COBIT 5 Enabler 3: Organisational Structures...................................................................................................................55
COBIT 5 Enabler 4: Culture, Ethics and Behaviour...........................................................................................................57
COBIT 5 Enabler 5: Information.........................................................................................................................................59
COBIT 5 Enabler 6: Services, Infrastructure and Applications..........................................................................................61
COBIT 5 Enabler 7: People, Skills and Competencies.......................................................................................................62
Annexures.................................................................................................................................................................................65
A. Glossary of Terms...........................................................................................................................................................65
B. List of Figures...................................................................................................................................................................68
C. List of Policies and Procedures........................................................................................................................................69
D. References........................................................................................................................................................................70
E. FAQs..................................................................................................................................................................................70

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 good 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 five chapters:
Chapter 1. What Is Personal Information?
Chapter 2. Indian Sensitive Personal Data or Information (SPDI) Protection Regulations
Chapter 3. How COBIT 5 Can Be Used to Secure SPDI
Chapter 4. Meeting Stakeholders Needs for Securing SPDI
Chapter 5. COBIT 5 Enablers for Securing SPDI
Chapter 1. What is Personal Information?

This chapter explains the meaning of personal information and why personal information is so important for us. Formal
definitions of terms like Personal Information (PI), Personally Identifiable Information (PII) and Sensitive Personal Data or
Information (SPDI) are given. Finally, the purpose and general principles involved in securing SPDI are explained.
Chapter 2. 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 3. How COBIT 5 Can Be Used to Secure SPDI

COBIT 5 is the latest edition of ISACAs 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 4. 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
Preface
Chapter 5. COBIT 5 Enablers for Securing SPDI
This key chapter provides reasonable security practices and procedures for securing SPDI. The chapter begins with an
introduction to COBIT 5 enablers and COBIT 5 enabler dimensions and is followed by detailed explanation of each
enabler as it relates to SPDI:
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 eleven 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 informations quality by defining goals and adopting good 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
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 focus 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 Indias 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) using COBIT 5.
The publication presents:
The know-why, that is to say, the reasons for securing sensitive personal data as required by Indias IT Act
The know-how of securing SPDI, from the risk mitigation, operational and implementation angles
2. What does each chapter cover?
Chapter 1 explains what is personal information. The know-why is explained in chapter 2. It explains
relevant provisions of the IT Act and the relevant rules under said Act.
The know-how is provided in the following chapters:
Chapter 3 explains COBIT 5 and how it can be used to secure SPDI.
Chapter 4 identifies the stakeholders and their needs for securing SPDI.
Chapter 5 builds the seven enablers that will help to secure SPDI.
1
2
3
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 Indias 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 Indias 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 Indias IT Acts 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 provided by COBIT 5.
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
The Information Technology Act, 2000, www.mit.gov.in/sites/upload_files/dit/files/downloads/itact2000/itbill2000.pdf

he Information Technology (Amendment) Act, 2008, www.mit.gov.in/sites/upload_files/dit/files/downloads/itact2000/it_amendment_act2008.pdf
T
Notifications from Ministry of IT, www.mit.gov.in/content/notifications

7. How was this book conceived?
This book was conceived by ISACAs 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.
8. How should you use

this publication?
Use this publication as a handy code of good 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 2 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 2. Body corporate,
explained in chapter 2, 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:
COBIT 54
COBIT 5: Enabling Processes 5
COBIT 5 Implementation 6
COBIT 5 for Information Security 7
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.
COBIT 5, www.isaca.org/cobit
COBIT 5: Enabling Processes, www.isaca.org/cobit/Documents/COBIT-5-Enabling-Processes-Introduction.pdf
6
COBIT 5 Implementation, www.isaca.org/cobit/Documents/COBIT-5-Implementation-Introduction.pdf
7
COBIT 5 for Information Security, www.isaca.org/COBIT/Pages/info-sec.aspx
4
5
Chapter 1
What Is Personal Information?
Chapter 1
Introduction
The creation of personal information about a person begins at birth. The hospital records and birth registry details are
the first entries relating to the personal information of a child. Additional personal information is generated in terms of
school records when the child starts his/her education. The childs health records are maintained by a doctor or a medical
facility. The childs name may also be entered into municipal records, census records and a ration card in due course. For a
teenager, additional personal records come into being, such as a bank account, mobile number, social networking account,
school and college records, and university records.
For an adult, the personal records start increasing exponentially. The urban adult has various bank accounts, credit cards,
debit cards, insurance records, income tax permanent account number (PAN), driving license, email IDs, passwords for
various applications including financial transactions, passport records, biometric records stored at the Government of
Indias UID (Unique Identification) scheme, service records, access cards, telephone numbers, and so on. Most of these
personal records remain active and in use even after retirement, as the financial transactions, banking transactions, health
records, etc., are very much in use until death. And, finally, the death certificate is also a personal record. The entire life
cycle of personal information is completed thus. In fact, the personal information may remain as a historical or statistical
record even when a person is deceased.
Before the Information Age, all these records existed in a highly dispersed state in various hard-bound registers and could
not be retrieved or accessed from online databases at the stroke of a key. The paper medium offered a degree of protection
of personal information against unauthorized access. Digitization of the records has opened up new security risks for the
information and now digital fortresses are needed to protect the databases.
Why Personal Information Is Important

Personal information points to a persons identity in each sphere of life, whether it is banking access, health care support,
insurance claims, income tax payments, airline or rail travel, foreign travel, education qualifications, or employment. A
person is identified, educated, employed, rewarded for good work, punished for crimes; every facet of the personal life is
recorded somewhere. If this record is stolen by a criminal and used to impersonate the person, a serious case of identity
theft could occur. A person could easily be robbed if his/her banking identity is stolen, or could be framed for criminal
activities if his/her personal records are tampered with. An impersonator could use an innocent persons access credentials
to gain unauthorized entry and commit a crime, for which the identity theft victim might suffer.
There are a number of definitions for personal information.
Personal Information (PI)

As defined by the IT Act, personal information is 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)

PII has not been defined by the IT Act. The definition below is taken from National Institute of Standards and Technology
(NIST) SP 800-122, Guide to Protecting the Confidentiality of Personally Identifiable Information (PII):
Any information about an individual maintained by an agency, including (1) any information that can be used
to distinguish or trace an individuals identity, such as name, social security number, date and place of birth,
mothers 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.

Sensitive Personal Data or Information (SPDI)
The IT Act has a specific category, sensitive personal data or information, defined below:
Such personal information 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
Purpose of Defining SPDI

From the list of personal information items, it is clear that the IT Act wants to protect persons against any misuse of these
specific items.
PasswordsPasswords are used for every electronic transaction. Unauthorized use of passwords can have serious
repercussions. For example, the bank account could be robbed, confidential information could be accessed and illegal
transactions could be carried out.
Financial information such as bank account, credit card, debit card or other payment instrument detailsThese are
very sensitive items. Any unauthorized access can have very serious financial implications .
Physical, physiological and mental health conditionsUnauthorized access to this information could result in serious
damage to personal interests. It could lead to embarrassment, blackmail, discrimination or denial of proper treatment,
which can cause grave bodily injury and even death.
Sexual orientationThis too is very sensitive information, leakage of which could lead to embarrassment and blackmail.
Medical records and historyUnauthorized access to this extremely sensitive personal information could lead to
embarrassment, blackmail or denial of proper treatment, causing grave bodily injury and even death.
Biometric informationThis information is collected to positively identify a person. Tampering with it could lead to
identity theft of a very serious nature as well denial of access to facilities subject to biometric information.
Why It Is Important to Secure SPDI

SPDI relates to select categories of PII. To provide an individual complete privacy protection, the entire PII should be
secured. This will likely need a full-fledged law for the protection of privacy in India. The IT Act has taken the initial steps
towards it and made it mandatory to secure SPDI for the restricted list of items given in the definition. These are the items
that define more critical data or information items that need to be protected on a priority basis.
General Principles for Securing Personal Information

Principles involved in securing personal information are mostly based on the eight fair information practices of the
Organisation for Economic Co-operation and Development (OECD):
1. C
ollection 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. D
ata 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. P
urpose 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 in either of the following instances:
a) With the consent of the data subject
b) By the authority of the law
10
Chapter 1
5. S
ecurity Safeguards Principle. Personal data should be protected by reasonable security safeguards against risks such
as loss or unauthorized access, destruction, use, modification or disclosure of data.
6. O
penness Principle. There should be a general policy of openness about developments, practices and policies with
respect to the 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. I ndividual 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
the individual
b) To have communicated to him/her, data relating to him/her:
i) Within a reasonable time
ii) At a charge, if any, that is not excessive
iii) In a reasonable manner
iv) In a form that is readily intelligible to him/her
c) To be given reasons if a request made under subparagraphs (a) and (b) is denied, and to be able to challenge such denial
d) To challenge data relating to him/her 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 that give effect to the
principles stated above.
These principles provide the general basis for the privacy and security requirements for SPDI given in the IT Act.
Use of COBIT 5 for Securing SPDI

COBIT 5 is a business framework for governance and management of enterprise IT. Compliance with the IT Act is
a business requirement and it has to be handled in a holistic manner. COBIT 5 is based on five principles and seven
enablers. Together, these will help an enterprise to meet the requirements of the IT Act by providing appropriate
governance and management guidance and direction for securing SPDI, thus achieving the enterprise governance objective
of risk optimization.
11

Page intentionally left blank
12
Chapter 2. Indian Sensitive Personal Data

or Information (SPDI) Protection Regulations
Chapter 2
Indian Sensitive Personal Data or Information (SPDI)
Protection Regulations
Objective
Securing SPDI is now mandated by Indias IT (Amendment) Act, 2008. This publication helps 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 5, 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. H
ow were specific privacy
provisions added to the IT Act?
The IT Act provides for legal recognition for:

Electronic records
Electronic signatures
Electronic transactions
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.
13

2. W
ho 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 numbers 18 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.
2. W
ho 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.)
14
Checklist
1. Is the entity concerned a firmsole 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. W
hat 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
Sexual orientation
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 IT 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 individuals identity, such as name, social
security number, date and place of birth, mothers 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?
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.
(See proviso to Rule 3 of

the Information Technology
[Reasonable Security Practices
and Procedures and Sensitive
Personal Data or Information]
Rules, 2011.)
4 B. W
hat 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 commercial 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.
5. What happens if the body corporate

fails to keep sensitive personal
data secure?
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.)
(See Section 43 A of the IT Act.)
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?
15

6. W
hat 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 IT Act that explain
reasonable security practices and procedures. Item 24 refers to the international standard
ISO/IEC 27001:2005, Information technologySecurity techniquesInformation security management
systemsRequirements, as being a Government approved standard for 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. W
hat are a body corporates
obligations as to privacy policy?
ule 4. Body corporate to provide policy for privacy and disclosure of information. (1) The body corporate
R
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 purpose 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?
Note: Although the IT Act does not say so specifically, the term contract here presumably refers to a
contract between the body corporate and the provider of information.
3. Do we have a privacy policy?
4. Is the personal information available for viewing by the people who provide their personal information?
8. W
here should the privacy policy be
posted? What should it cover?
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 Indias IT Act and the Rules under that Act, adapting a prescribed
standard appropriately may be necessary, to ensure comprehensive compliance.
16

8. Where should the privacy policy be
posted? What should it cover? (cont.)
ow do we get consent for

9. H
collection or usage of
personal data?
Checklist
1. Is our privacy policy clear? Have we obtained feedback after review by persons who have provided their
personal information? Have we provided an email address to which visitors could write for clarifications if
the policy is not clear to them?
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?
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,
Sensitive Personal Data Information] Government of India, issued a press release on 24 August 2011 stating, among other things:
Rules, 2011.)
Further, in Rule 5(1) consent includes consent given by any mode of electronic communication.
Notes:
Hence, web-based consent or mobile-message-based consent could qualify as valid consent.
It is logical to assume that the consent should be available for retrieval as long as the SPDI is maintained.
Care must be taken to retain such consent until all copies of the SPDI are destroyed or deleted.
Checklist
1. Have we obtained consent from the provider of personal data?
(Note: It is a good practice to check if the provider of the personal information is a major, that is to say,
at least 18 years of age, because consent obtained from a minor may not be adequate in law.)
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. W
hat is lawful purpose for
collection of sensitive
personal data?
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
(See Rule 5 [2] [a] of the

Checklist
Information Technology
[Reasonable Security Practices and 1. Have we defined the purpose for collection of sensitive personal data?
Procedures and Sensitive Personal 2. Is such purpose connected with one or more of our functions or activities?
Data or Information] Rules, 2011.)
Note: It is a good practice to check if the provider of the personal information is a major, that is to say, at
least 18 years of age, because consent obtained from a minor may not be adequate in law.)
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?
17

11. H
ow do we collect sensitive
personal data?
(See Rule 5 [3] of the Information
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. 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?
6. Has a responsible officer of the body corporate signed-off to signify that the measures stated above
have been undertaken?
12. H
ow do we address retention/use?
13. W
hat are the personal
information providers rights
to review accuracy, etc., of his/
her information with the body
corporate?
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?
7. If the personal data resides on multiple computers and/or at multiple locations, have we taken care to
ensure that the aforesaid is complied with in respect of all such computers?
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
Notes:
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.
Although the word feasible means possible, practical, viable or reasonable, bodies corporate
should consider whether they would be in a position to establish that any required amendments or
corrections were not feasible, in the event of a legal challenge or investigation.
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?
18

14. Is the body corporate obligated
for authenticity?
(See proviso to Rule 5 [6] of
[Reasonable Security Practices and
Procedures and Sensitive Personal
15. W
hat is the opt-out option for the
SPDI provider?
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.
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?
16. W
hat does the body corporate or
any person on its behalf shall keep
the information secure mean?
Information] Rules, 2011. Also
Section 72 A of the IT Act.)
17. Do we have a grievance officer and
mechanism?
18. W
hat are the non-disclosure
duties?
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
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. H
ave 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?
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)?
ISO/IEC 27001:2005, Information technologySecurity techniquesInformation security management systemsRequirements
19

19. Is there any restriction on transfer
to a mandated government
agency?
S PDI 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
(See proviso to Rule 6 [1] of
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.
[Reasonable Security Practices and 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.
It may be a good practice to alert an information provider that his or her data has been shared with a
government agency, except, of course, where the government or court order restrains the body corporate
from doing so.
Checklist
1. D
o 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?
Determine if the agency has stated specifically that such shared data will not be published or shared
with any other person?
20. Is there a duty not to publish?
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?
21. W
hat does no further disclosure
by the third party, mean?
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 forbid from
further disclosing such data?
2. Do we have a mechanism in place to ensure the above?
hat are the rules for transfer

22. W
of information?
20
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. W
hat constitutes compliance
A body corporate or a person on its behalf shall be considered to have complied with reasonable security
with requirements of reasonable
practices and procedures, if they have implemented such security practices and standards and have a
security practices and procedures? 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.
Note: Refer to item 24 below for options of government approved standard.
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. W
hat are the options of
government-approved standards?
The international standard ISO/IEC 27001:2005, Information technologySecurity techniquesInformation

security management systemsRequirements 8 is one such standard referred to in sub-Rule (1).
(See Rules 8 [2] and 8 [3] of

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
[Reasonable Security Practices and codes of best practices duly approved and notified by the Central Government for effective implementation.
Checklist
1. H
ave we adopted and implemented the international standard ISO/IEC 27001:2005, Information
technologySecurity techniquesInformation security management systemsRequirements (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 organisations 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?
25. W
hat are the audit requirements?
(See Rules 8 [4] of the Information
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. H
ave 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?
21

26. W
ho will determine default?
(See Section 46 of the IT Act.)
27. How will compensation be

decided?
28. What is the 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.)
29. Could there be remedies outside
the IT Act?
30. What are Indias personal data
protection requirements (other
than those under 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.
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
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.
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.
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 partys 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 laws
The 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 1983This Act provides for
confidentiality in bank transactions. For example, banks are obliged to keep in confidence details of
its customers transaction in the books of the bank, to protect the customers interests and reputation.
3. Privacy rights read into certain fundamental rights
In 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.
22

Conclusion
This chapter has provided the requisite know-why, that is to say, the reasons for securing sensitive personal data as
required by Indias 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.
23

24
Chapter 3
How COBIT 5 Can Be Used to Secure SPDI
Chapter 3
Executive 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 managementboth in the business and IT functionsmust 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 (see figure 1) 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 1COBIT 5 Principles
1. Meeting
Stakeholder
Needs
5. Separating
Governance
From
Management
4. Enabling a
Holistic
Approach
2. Covering the
Enterprise
End-to-end
COBIT 5
Principles
3. Applying a
Single
Integrated
Framework
Source: COBIT 5, figure 2
25

COBIT 5 is based on five key principles (shown in figure 1) for governance and management of enterprise IT:
Principle 1: Meeting Stakeholder NeedsEnterprises 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-endCOBIT 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 everyoneinternal and externalthat is relevant to governance and management of enterprise
information and related IT.
Principle 3: Applying a Single, Integrated FrameworkThere are many IT-related standards and good 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 ApproachEfficient 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 ManagementThe 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 5s 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.
26
Chapter 3
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?
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
SPDIs 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.
27

28
Chapter 4
Meeting Stakeholders Needs for Securing SPDI
Chapter 4
This 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 2COBIT 5 Goals Cascade Overview
Stakeholder Drivers
(Environment, Technology Evolution, )
Influence
Stakeholder Needs
Benefits
Realisation
Risk
Optimisation
Resource
Optimisation
Cascade to
Enterprise Goals
Cascade to
IT-related Goals
Cascade to
Enabler Goals
29

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 bodyBoard, chairman
ManagementCEO , 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 executionBusiness 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 3Key Roles, Activities and Relationships
Roles, Activities and Relationships

Owners and
Stakeholders
Delegate
Accountable
Governing
Body
Set Direction
Management
Monitor
Instruct and
Align
Report
Operations
and
Execution
What are the external stakeholder

questions for securing SPDI?
These questions were revised 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 revised 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.
30
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
Chapter 4
2. How do I manage
performance of IT?
3. H
ow can I best exploit new
technology for new strategic
opportunities?
Y
Y
9.
10.
11.
12.
13.
6. What are the (control)

requirements for information?
8. Am I running an efficient and

resilient IT operation?
10. Do I have enough people

for IT? How do I develop
and maintain their skills,
and how do I manage their
performance?
13. How do I improve business

agility through a more
flexible IT environment?
14. Do IT projects fail to deliver

what they promisedand
if so, why? Is IT standing
in the way of executing the
business strategy?
Y
Y
Y
Y
12. Is the information I am

processing well secured?
17.
9. H
ow 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?
11. How do I get assurance

over IT?
16.
7. D
id I address all IT-related
risk?
5. H
ow dependent am I on
external providers? How
well are IT outsourcing
agreements being managed?
How do I obtain assurance
over external providers?
4. How do I best build and

structure my IT department?
15.
14.
Product and business innovation

culture
8.
Skilled and motivated people
Managed business change

programmes
7.
Compliance with internal policies
Optimisation of business process

costs
6.
Operational and staff productivity

functionality
Optimisation of service delivery

costs
5.
Information-based strategic
decision making
4.
Agile responses to a changing

business environment
3.
Business service continuity and

availability
2.
Customer-oriented service culture
Compliance with external laws

and regulations
1.
Financial transparency
Managed business risk

(safeguarding of assets)
1. H
ow do I get value from the
use of IT? Are end users
satisfied with the quality of
the IT service?
Portfolio of competitive products

and services
STAKEHOLDER NEEDS
Stakeholder value of business

investments
Figure 4Mapping COBIT 5 Enterprise Goals to Governance and Management Questions
Y = Yes
31

19. Are sufficient IT resources

and infrastructure available
to meet required enterprise
strategic objectives?
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 = Yes
32
12.
13.
14.
15.
Y
Y
16.
Product and business innovation

culture
11.
10.
18. How much of the IT effort

goes to fighting fires rather
than to enabling business
improvements?
21. Are the total IT effort and

investments transparent?
9.
17. What has been the average

overrun of the IT operational
budgets? How often and
how much do IT projects go
over budget?
20. How long does it take to

make major IT decisions?
8.
7.
Managed business change

programmes
16. What concrete vital primary

business processes are
dependent on IT, and what
are the requirements of
business processes?

costs

functionality
6.
Optimisation of service delivery

costs
15. H
ow critical is IT to
sustaining the enterprise?
What do I do if IT is not
available?
5.
Information-based strategic
decision making
4.
Agile responses to a changing

business environment
Compliance with external laws

and regulations
3.
Business service continuity and

availability
Managed business risk

(safeguarding of assets)
2.
Portfolio of competitive products

and services
1.
STAKEHOLDER NEEDS
Stakeholder value of business

investments
Figure 4Mapping COBIT 5 Enterprise Goals to Governance and Management Questions (cont.)
17.
Chapter 4
How do the enterprise goals for SPDI
relate to the governance objective?
Tracing the enterprise goals in COBIT 5s 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 5Mapping COBIT 5 Enterprise Goals to Governance Objectives

Governance Objectives
BSC Dimension
Enterprise Goals
Benefits
Realisation
1. Stakeholder value of business investments
Financial
2. Portfolio of competitive products and services
Financial
Financial
Risk
Optimisation
Resource
Optimisation
S
3. Managed business risks (safeguarding of assets)
Financial
4. Compliance with external laws and regulations
Financial
5. Financial transparency
Customer
6. Customer-oriented service culture
Customer
7. Business service continuity and availability
Customer
8. Agile responses to a changing business environment
Customer
9. Information-based strategic decision making
Customer
10. Optimisation of service delivery costs
Internal
11. Optimisation of business process functionality
Internal
12. Optimisation of business process costs
Internal
13. Managed business change programmes
Internal
14. Operational and staff productivity
Internal
15. Compliance with internal policies
Learning and
Growth
16. Skilled and motivated people
Learning and
Growth
17. Product and business innovation culture
P = Primary
S
S
P
S
P
S
P
P
P
S = Secondary
Adapted from: COBIT 5, figure 5
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.
33

Figure 6Mapping COBIT 5 Enterprise Goals to IT-related Goals
Stakeholder value of business investments
Portfolio of competitive products and services
Managed business risk (safeguarding of assets)
Compliance with external laws and regulations
Business service continuity and availability
Agile responses to a changing business environment
Information-based strategic decision making
Optimisation of service delivery costs
Optimisation of business process functionality
Optimisation of business process costs
Managed business change programmes
Product and business innovation culture
Enterprise Goal
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
Internal
Customer
Financial
IT-related Goal
01
Alignment of IT and business strategy
02
IT compliance and support for business

compliance with external laws and
regulations
Learning
and
Growth
Customer
S
S
04
Managed IT-related business risk
05
Realised benefits from IT-enabled

investments and services portfolio
06
Transparency of IT costs, benefits and risk
07
Delivery of IT services in line with business

requirements
08
Adequate use of applications, information

and technology solutions
09
IT agility
10
Security of information, processing

infrastructure and applications
11
Optimisation of IT assets, resources and

capabilities
12
Enablement and support of business

processes by integrating applications and
technology into business processes
Delivery of programmes delivering

benefits, on time, on budget, and meeting
requirements and quality standards
14
Availability of reliable and useful

information for decision making
15
IT compliance with internal policies
16
Competent and motivated business and

IT personnel
17
Knowledge, expertise and initiatives for

business innovation
P = Primary
S = Secondary
S
P
S
S
S
S
S
P
S
P
S
S
Internal
P
P
Commitment of executive management for

making IT-related decisions
03
13
34
Financial
Learning
and
Growth
S
S
S
S
P
P
P
S
S
P
S
P
P
S
Chapter 4
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 7Summary of the Selected IT-related Goals
IT Goal
Number
IT-related Goal
Associated With
IT BSC Dimension
Priority
Comments
01
Financial
Not relevant
02
IT compliance and support for business compliance with external laws and regulations
Financial
Accepted
04
Financial
Accepted
10
Security of information, processing infrastructure and applications
Internal
Accepted
14
Availability of reliable and useful information for decision making
Internal
Not relevant
15
Internal
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.
35

36
Chapter 5
COBIT 5 Enablers for Securing SPDI
Chapter 5
Reasonable 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 eleven 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 good 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 workin 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 8COBIT 5 Enterprise Enablers
2. Processes
3. Organisational
Structures
4. Culture, Ethics
and Behaviour
1. Principles, Policies and Frameworks
5. Information
6. Services,
Infrastructure
and Applications
7. People,
Skills and
Competencies
Resources
37

COBIT 5 Enabler Dimensions
All enablers have a set of common dimensions. This set of common dimensions (figure 9):
Provides a common, simple and structured way to deal with enablers
Allows an entity to manage its complex interactions
Facilitates successful outcomes of the enablers
Enabler Performance
Management
Enabler Dimension
Figure 9COBIT 5 Enablers: Generic
Stakeholders
Goals
Life Cycle
Good Practices
Internal
Stakeholders
External
Stakeholders
Intrinsic Quality
Contextual Quality
(Relevance,
Effectiveness)
Accessibility and
Security
Plan
Design
Build/Acquire/
Create/Implement
Use/Operate
Evaluate/Monitor
Update/Dispose
Practices
Work Products
(Inputs/Outputs)
Are Stakeholders
Needs Addressed?
Are Enabler
Goals Achieved?
Is Life Cycle
Managed?
Are Good Practices

Applied?
Metrics for Achievement of Goals

(Lag Indicators)
Metrics for Application of Practice

(Lead Indicators)
The enabler goals are the final step in the COBIT 5 goals cascade. Goals can be further split up in different categories:
Intrinsic qualityThe extent to which enablers work accurately, objectively and provide accurate, objective and
reputable results
Contextual qualityThe extent to which enablers and their outcomes are fit for purpose given the context in which
they operate. For example, outcomes should be relevant, complete, current, appropriate, consistent, understandable
and easy to use.
Access and securityThe extent to which enablers and their outcomes are accessible and secured, such as:
Enablers are available when, and if, needed.
Outcomes are secured, i.e., access is restricted to those entitled and needing it.
Life cycleEach enabler has a life cycle, from inception through an operational/useful life until disposal. This applies
to information, structures, processes, policies, etc. The phases of the life cycle consist of:
Plan (includes concepts development and concepts selection)
Design
Build/acquire/create/implement
Use/operate
Evaluate/monitor
Update/dispose
Good practicesFor each of the enablers, good practices can be defined. Good practices support the achievement of
the enabler goals. Good practices provide examples or suggestions on how best to implement the enabler, and what work
products or inputs and outputs are required. COBIT 5 provides examples of good practices for some enablers provided by
COBIT 5 (e.g., processes). For other enablers, guidance from other standards, frameworks, etc., can be used.
Enabler Performance Management
Enterprises expect positive outcomes from the application and use of enablers. To manage performance of the enablers, the
following questions will have to be monitored and thereby subsequently answeredbased on metricson a regular basis:
Are stakeholder needs addressed?
Are enabler goals achieved?
Is the enabler life cycle managed?
Are good practices applied?
38
Chapter 5
The first two bullets deal with the actual outcome of the enabler. The metrics used to measure to what extent the goals are
achieved can be called lag indicators.
The last two bullets deal with the actual functioning of the enabler itself, and metrics for this can be called lead indicators.
COBIT 5 Enabler 1: Principles, Policies and Frameworks

Stakeholders
External and internal stakeholders of SPDI have been defined in Chapter 4. These are also the stakeholders
for principles, policies and frameworks.
Principles
Principles involved in securing SPDI are broadly based on the eight fair information practices of OECD:9
1. C
ollection 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. D
ata 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. U
se 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. S
ecurity 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. O
penness 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. A
ccountability Principle. A data controller should be accountable for complying with measures which
give effect to the principles stated above.
Framework
The IT Act provides the necessary framework for creation of various policies for SPDI.
Life Cycle
The policies and procedures should follow any changes made to the IT Act or rules.
Good Practices
The outline of policies and procedures detailed below provide the necessary guidance based on good
practices suggested in COBIT 5 and COBIT 5 for Information Security.
Policies and procedures required for

securing SPDI
1. Privacy policy for SPDI

2. Procedures for the privacy policy for SPDI
3. SPDI security policies
4. 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
Scope
The privacy policy should include answers to the following questions based on the requirements of IT Act
summarised in the indicated checklists.
39

Does the policy explain the type of
personal information that we collect?
Have we obtained the consent?
ChecklistChapter 2, Item 3
the aforesaid definition of sensitive
personal data?
Does the policy explain why we collect

and use the personal data?
Have we disclosed that we are

collecting the data?
Have we disclosed the

retention policy?
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?
Have the contact details of the

grievance officer been provided?
40
Checklist Chapter 2, 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?
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?
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?
they have provided?
not complete)?
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?
1. H
Chapter 5
Have the conditions been explained
under which the data could
be disclosed?
Have the conditions been explained

under which the data could be
transferred to government agencies
or third parties?

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)?
1. D
1. Do we obtain agreement from third parties with whom we share sensitive personal data to refrain from
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?
Have the reasonable security policies

and procedures that are adopted
to ensure the security of SPDI
been explained?
Have any penalties been defined for

the breach of the privacy policy by
internal or external entities handling
the SPDI?

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?
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.)
As per chapter 5, 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.
41

2. Procedures for privacy policy
2.1 Procedure for identifying SPDI
Key points:
Create a master list of 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
Sexual orientation
Give examples of each of the items for clarification.
Responsibility:
CPO
the aforesaid definition of sensitive personal data?
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.
Responsibility:
CPO
they have provided?
not complete)?
42
Chapter 5
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.
Responsibility:
CPO
1. H
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.
Responsibility:
CPO
1. D
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.
Responsibility:
CPO
1. Do we obtain agreement from third parties with whom we share sensitive personal data to refrain from
2.8 Procedure for penalties for any

breaches by internal or external
entities handling SPDI
As per chapter 5, 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
43

2.9 P
rocedure 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.
Responsibility:
CPO
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 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
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
44
Chapter 5
3.2 Ethics policy for SPDI

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
To be updated/revalidated by CPO upon any change in business activities handling SPDI or at least
once a year
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
To be updated/revalidated by CRO, assisted by CPO, upon any change in business activities handling SPDI
or at least once a year
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 incident response policy
As per DSS02, COBIT 5 and COBIT 5 for Information Security:

Goals
To respond to any incident involving SPDI in a timely manner to contain and mitigate the damage and
recover business activities
Validity
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
45

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
Validity
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
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
Validity
To be updated/revalidated by CLO, assisted by CPO, upon any change in the IT Act or Rules or at least
once a year
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.
Validity
behalf of the enterprise or internal departments providing any services related to handling SPDI
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
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
46
Chapter 5
4.2 P
rocedure 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 and CISO
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.
Responsibility:
CISO
4.7 Procedure for managing network

and connectivity security

Key points:
Manage network and connectivity security to prevent attacks on SPDI.
Responsibility:
CISO
4.8 Procedure for managing

endpoint security

Key points:
Secure endpoints at a level adequate to protect SPDI.
Responsibility:
CISO
47

4.9 P
rocedure 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.
Responsibility:
CISO
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.
Responsibility:
CISO
4.11 Procedure for managing sensitive

documents and output devices

Key points:
Manage sensitive documents and output devices handling SPDI.
Responsibility:
CISO
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.
Responsibility:
CISO
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.
Responsibility:
CISO
48
Chapter 5
4.16 P
rocedure 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.
Responsibility:
CISO
4.17 Procedure for secure

transmission of SPDI

Key points:
Securely send SPDI in hard copy.
Securely encrypt and transmit SPDI in digital form.
Responsibility:
CISO
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.
Responsibility:
CISO
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.
Responsibility:
CISO

security at the syntactic layer
for SPDI

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

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.
Responsibility:
CIO

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.
Responsibility:
CIO
49

4.23 P
rocedure for maintaining
security at the social-world layer

Key points:
Identify information unsuitable for display.
Prevent disclosure of such information.
Responsibility:
CPO
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
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:
GovernanceContains five governance processes; within each processevaluate, direct and monitor (EDM)
ManagementContains 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)
50
Chapter 5
Figure 10 shows the complete set of 37 governance and management processes within COBIT 5.
Figure 10COBIT 5 Illustrative Governance and Management Processes
Processes for Governance of Enterprise IT

Evaluate, Direct and Monitor
EDM01 Ensure
Governance
Framework Setting
and Maintenance
EDM02 Ensure
Benefits Delivery
EDM03 Ensure
Risk Optimisation
EDM04 Ensure
Resource
Optimisation
EDM05 Ensure
Stakeholder
Transparency
Align, Plan and Organise

APO01 Manage
the IT Management
Framework
APO08 Manage
Relationships
APO02 Manage
Strategy
APO09 Manage
Service
Agreements
Monitor, Evaluate
and Assess
APO03 Manage
Enterprise
Architecture
APO04 Manage
Innovation
APO05 Manage
Portfolio
APO06 Manage
Budget and Costs
APO10 Manage
Suppliers
APO11 Manage
Quality
APO12 Manage
Risk
APO13 Manage
Security
BAI04 Manage
Availability
and Capacity
BAI05 Manage
Organisational
Change
Enablement
BAI06 Manage
Changes
DSS04 Manage
Continuity
DSS05 Manage
Security
Services
DSS06 Manage
Business
Process Controls
APO07 Manage
Human Resources
MEA01 Monitor,
Evaluate and Assess
Performance and
Conformance
Build, Acquire and Implement

BAI01 Manage
Programmes and
Projects
BAI02 Manage
Requirements
Definition
BAI03 Manage
Solutions
Identification
and Build
BAI08 Manage
Knowledge
BAI09 Manage
Assets
BAI10 Manage
Configuration
BAI07 Manage
Change
Acceptance and
Transitioning
MEA02 Monitor,
Evaluate and Assess
the System of Internal
Control
Deliver, Service and Support

DSS01 Manage
Operations
DSS02 Manage
Service Requests
and Incidents
DSS03 Manage
Problems
MEA03 Monitor,
Evaluate and Assess
Compliance With
External Requirements
Processes for Management of Enterprise IT

IT Processes Applicable for Securing SPDI

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

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). Eleven processes (out of a total of 37 processes) have been identified to help in meeting
the four IT-related goals.
See figure 11 below (based on figure 23, Appendix C, of COBIT 5).
51
Align, Plan and Organise
P = Primary
52
S = Secondary
compliance with external laws and regulations
Commitment of executive management
for making IT-related decisions
Delivery of IT services in line with
business requirements
IT agility
Optimisation of IT assets, resources
and capabilities
Enablement and support of business processes
by integrating applications and technology into
business processes
Delivery of programmes delivering benefits,
on time, on budget, and meeting requirements
and quality standards
Competent and motivated
business and IT personnel
business innovation

Figure 11Mapping COBIT 5 IT-related Goals to Processes
IT-related Goal
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
COBIT 5 Process
Financial
EDM01
Ensure Governance
Framework Setting and
Maintenance
P
EDM02
Ensure Benefits Delivery
P
EDM03
Ensure Risk Optimisation
S
EDM04
Ensure Resource
Optimisation
S
EDM05
Ensure Stakeholder
Transparency
S
S
P
APO01
Manage the IT Management
Framework
P
P
S
S
APO02
Manage Strategy
P
S
S
S
APO03
Manage Enterprise
Architecture
P
S
S
S
APO04
Manage Innovation
S
S
P
APO05
Manage Portfolio
P
S
S
P
S
APO06
Manage Budget and Costs
S
S
S
P
P
APO07
Manage Human Resources
P
S
S
APO08
Manage Relationships
P
S
S
S
S
P
S
APO09
Manage Service Agreements
S
APO10
Manage Suppliers
APO11
Manage Quality
APO12
Manage Risk
APO13
Manage Security
S
S
S
P
S
S
P
S
S
Customer
S
S
P
P
P
P
S
P
S
S
S
S
S
S
P
P
Internal
P
S
S
S
S
P
P
P
P
S
S
S
S
P
S
S
S
S
P
P
S
P
P
S
S
S
P
P
P
S
S
S
S
S
P
S
S
S
S
S
P
S
S
P
S
S
P
S
P
S
S
S
S
S
S
S
P
P
S
S
S
P
S
S
S
S
P
P
Learning
and
Growth
S
S
S
S
S
S
S
S
S
S
S
S
S
S
S
S
S
P
S
S
P
S
S
P
S
S
S
P
P
P
S
S
S
S
S
S
P
P
S
S
S
S
S
P
S
Chapter 5
Figure 11Mapping COBIT 5 IT-related Goals to Processes (cont.)

compliance with external laws and regulations
Commitment of executive management

for making IT-related decisions

Delivery of IT services in line with

business requirements

IT agility

Optimisation of IT assets, resources

and capabilities
Enablement and support of business processes

by integrating applications and technology into
business processes
Delivery of programmes delivering benefits,

on time, on budget, and meeting requirements
and quality standards

Competent and motivated

business and IT personnel

business innovation
IT-related Goal
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
Monitor, Evaluate and Assess
Deliver, Service and Support
Build, Acquire and Implement
COBIT 5 Process
Financial
Customer
BAI01
Manage Programmes and

Projects
BAI02
Manage Requirements
Definition
BAI03
Manage Solutions
Identification and Build
BAI04
Manage Availability and

Capacity
BAI05
Manage Organisational
Change Enablement
BAI06
Manage Changes
BAI07
Manage Change Acceptance

and Transitioning
BAI08
Manage Knowledge
BAI09
Manage Assets
BAI10
Manage Configuration
DSS01
Manage Operations
DSS02
Manage Service Requests

and Incidents
DSS03
Manage Problems
DSS04
Manage Continuity
DSS05
Manage Security Services
DSS06
Manage Business Process

Controls
MEA01
Monitor, Evaluate and

Assess Performance and
Conformance
MEA02
MEA03
P = Primary
Internal
S
S
S
P
S
S

Compliance With External
Requirements

the System of Internal
Control
Learning
and
Growth
S = Secondary
53

The identified IT processes for securing SPDI are:
Evaluate, Direct and Monitor (EDM)
EDM03 Ensure Risk Optimisation
Align, Plan and Organise (APO)
APO01 Manage the IT Management Framework
APO12 Manage Risk
APO13 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
DSS06 Manage Business Process Controls
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 5s governance and management processes is provided in COBIT 5: Enabling
Processes. For each process the following information is included:
Process identification:
Process labelThe domain prefix (EDM, APO, BAI, DSS, MEA) and the process number
Process nameA short description, indicating the main subject of the process
Area of the processGovernance or management
Domain name
Process descriptionAn overview of what the process does and a high-level description of how the process
accomplishes its purpose
Process purpose statementA description of the overall purpose of the process
Goals cascade informationReference 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 metricsA set of process goals and a limited number of example metrics
RACI chartA 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 practicesFor each practice:
Practice title and description
Practice inputs and outputs, with indication of origin and destination
Process activities, further detailing the practices
Related guidanceReferences to other standards and direction to additional guidance
54
Chapter 5
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 bodyBoard, CEO
Management committeeCEO, CFO, CIO, CISO, CPO, CRO, CHRO, CLO and all the C-level executives of
the organisation
Operation and execution teamBusiness 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
Members: ManagementCEO, 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 incidents and reporting to the board
55

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
Life cycle and good practices
56
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.
board should monitor performance, compliance and progress against the agreed-on direction and
. The
objectives.
M
anagement 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 boards 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.
management committee should meet at least once a year to review the effectiveness of
. The
the privacy and security policies, any privacy breaches, and the actions taken to prevent future
occurrences.
management committee should provide adequate resources to the operations and execution
. The
committee.
committee should be headed by CEO or his designate, that should report the progress to the board.
. The
O
peration 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.
team, in turn, may delegate tasks to various groups with specific responsibilities, whose activities
. The
will be closely monitored by the team.
team should meet at least once every six months to review the status of the implementation.
. The
. The operation and execution teams responsibility should be held by the CISO, assisted by the CPO/
grievance officer.
CISO should report progress to the management committee.
. The
Chapter 5
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 enterprises day-to-day life. For each of the behaviours defined, the following
attributes are described in this section:
Organisational ethicsDetermined by the values by which the enterprise wants to live
Individual ethicsDetermined 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
LeadershipWays 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
Behaviours
Each 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 enterprises 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).
57

Leadership
The 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.
58
Chapter 5
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 12), 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 12COBIT 5 Information Cycle
Generate and Process
Business Processes
Drive
IT Processes
Value
Data
Transform
Information
Transform
Knowledge
Create
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 ownersThe individuals whose personal information is collected, stored and processed. They
are the major stakeholders. The organisations privacy policy assures the SPDI owners of the security
surrounding the sensitive personal information collected from them.
SPDI custodiansResponsible 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 consumersResponsible for using the information. They could be internal or external stakeholders
who need to provide some service based on the SPDI.
SPDI guardiansExternal stakeholders (such as regulatory bodies) who are concerned with adequacy of
the steps taken to protect the SPDI and full compliance with the law
GoalIntrinsic Quality
AccuracyThe 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.
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.
59

GoalContextual and representational Relevancy SPDI should be collected only for lawful purpose connected with functions or activities of the
quality
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.
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
UnderstandabilityThe 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.
GoalSecurity/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.
Additional Goals for SPDI
ConsentPrior consent from the SPDI producer should be obtained for collection and use of the SPDI.
NoticeA notice in simple and clear language should be given prior to collection of SPDI.
Collection limitationCollection of the SPDI should be relevant to the identified purpose only.
Use limitationUse of SPDI should be limited to the stated purpose only.
IntegrityThe SPDI should be accurate and free from errors.
Life cycle
PlanSPDI 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.
DesignThe 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/acquireThe 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 2 will also prove helpful.
Use/operate:
S
toreStorage 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.
S
hareSPDI can be shared only with other organisations under lawful contract and only when the
receiving organisation also provides an equal level of security.
U
seThe use of SPDI must be restricted to only the purpose for which it was collected.
D
estroyThe 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.
Good practices
SPDI should be secured at various layers.
Good practicesPhysical-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.
60
Chapter 5
Good practicesEmpirical 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.
Good practicesSyntactic 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.
Good practicesSemantic 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 typeThis 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 currencyAn indicator should be built to display the currency of SPDI.
Information levelThe 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.
Good practicesPragmatic layer
The following four attributes are required for managing SPDI and should be built into the information system:
Retention periodThe attribute that identifies how long SPDI can be retained before it is destroyed.
SPDI statusThe attribute that identifies whether the SPDI is operational or historical.
NoveltyThe attribute that identifies whether the SPDI creates new knowledge or confirms existing
knowledge, i.e., information vs. confirmation.
ContingencyThe attribute that identifies the information that is required to precede this information (for
it to be considered information).
Good practicesSocial-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.
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.
61

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 incident response.
Secure legal services for SPDI.
Provide SPDI audit services.
Provide security and alert services for SPDI security-related events.
Offer grievance redressal services.
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 ChairmanThese stakeholders need proper education to ensure that they clearly
understand their accountability for SPDI and possible legal repercussions.
M
anagementThe 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 teamThese 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 staffThese 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:
Stakeholders Who Would
Benefit From These Skills
Process Domain
Examples of Skill Categories

(EDM)
Governance of enterprise IT with Board and chairman,

emphasis on SPDI
management committee
Deliver, Service and Support (DSS) S ervice desk and incident

management
Security administration
Operation and the execution team

(MEA)
Compliance review
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.
62
Chapter 5
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 the meaning of personal information and why personal information is so important for us.
Various privacy related terms were formally defined. The purpose and general principles involved in securing SPDI
were explained.
Chapter 2 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 3 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 4 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 5 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.
63

64
Annexures
Annexures
Annexure AGlossary of Terms
TERM
Accountable party (RACI)
DEFINITION
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 users eligibility to access computerised
information
Scope 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 enterprises 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
65
Securing Sensitive Personal Data or Information:

Using COBIT 5 for Indias IT Act
TERM
COBIT 5
DEFINITION
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 the
COBIT 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 contextTechnological factors that affect an organisations ability to extract value
from data
Data contextData accuracy, availability, currency and quality
Skills and knowledgeGeneral experience, and analytical, technical and business skills
Organisational and cultural contextPolitical factors, and whether the organisation prefers data
to intuition
Strategic contextStrategic 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
CEOChief Executive Officer

CFOChief Finance Officer
CIOChief Information Officer
CISOChief Information Security Officer
CPOChief Privacy Officer
CROChief Risk Officer
CHROChief Human Resources Officer
CLOChief 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 enterprises 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.
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.
66
Annexures
TERM
DEFINITION
Information
An asset that, like other important business assets, is essential to an enterprises 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 enterprises
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 SMARTspecific, 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 IT 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 enterprises 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)
67

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 enterprises risk appetite.
Services
See IT service
Skill
The learned capacity to achieve predetermined results
SPDISensitive 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
Sexual orientation
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 BList of Figures

Figure 1COBIT 5 Principles.................................................................................................................................................25
Figure 2COBIT 5 Goals Cascade Overview........................................................................................................................29
Figure 3Key Roles, Activities and Relationships.................................................................................................................30
Figure 4Mapping COBIT 5 Enterprise Goals to Governance and Management Questions...............................................31
Figure 5Mapping COBIT 5 Enterprise Goals to Governance Objectives...........................................................................33
Figure 6Mapping COBIT 5 Enterprise Goals to IT-related Goals.......................................................................................34
Figure 7Summary of the Selected IT-related Goals.............................................................................................................35
Figure 8COBIT 5 Enterprise Enablers.................................................................................................................................37
Figure 9COBIT 5 Enablers: Generic...................................................................................................................................38
Figure 10COBIT 5 Illustrative Governance and Management Processes...........................................................................51
Figure 11Mapping COBIT 5 IT-related Goals to Processes.................................................................................................52
Figure 12COBIT 5 Information Cycle.................................................................................................................................59
68
Annexures
Annexure CList of Policies and Procedures
Policies and Procedures Required for Securing SPDI are explained in detail in Chapter 5, enabler 1.
1. Privacy Policy for SPDI
2. Procedures for Privacy Policy
2.1 Procedure for identifying SPDI
2.2 Procedure for identifying business processes using SPDI
2.3 Procedure for obtaining consent
2.4 Procedure for allowing access to SPDI for review by the provider
2.5 Grievances redressal procedure
2.6 Procedure for providing access to the Government agencies
2.7 Procedure for transferring / sharing data with 3rd parties
2.8 Procedure for penalties for any breaches by internal or external entities handling SPDI
2.9 Procedure for meeting intrinsic quality goals for SPDI
2.10 Procedure for meeting contextual and representational quality goals for SPDI
2.11 Confidentiality Agreement for outsourcing or insourcing of services for SPDI
3. SPDI Security Management Policies
3.1 SPDI security policy
3.2 Ethics policy for SPDI
3.3 Risk management policy
3.4 SPDI incident response policy
3.5 SPDI security safeguards review policy
3.6 Compliance policy for SPDI with IT Act
3.7 Outsourcing and Insourcing policy for SPDI
4. SPDI Security Procedures
4.1 Risk management procedure
4.2 Procedure for collection, classification and analysis of SPDI related risks
4.3 Procedure for estimating business impact for SPDI related risks
4.4 Procedure to identify scope, boundary of the SPDI security management system
4.5 Procedure for SPDI incident response
4.6 Procedure for protection against malware
4.7 Procedure for managing network and connectivity security
4.8 Procedure for managing endpoint security
4.9 Procedure for managing user identity and logical access, to ensure security/accessibility of SPDI
4.10 Procedure for managing physical access to SPDI assets
4.11 Procedure for managing sensitive documents and output devices
4.12 Procedure for monitoring the infrastructure for security-related events
4.13 Procedure for reviewing the SPDI security controls and safeguards
4.14 Procedures for reviewing the SPDI controls and safeguards with IT Act requirements
4.15 Procedure for secure storage of SPDI
4.16 Procedure for destruction/disposal of SPDI
4.17 Procedure for secure transmission of SPDI
4.18 Procedure for maintaining audit log for access to SPDI
4.19 Procedure for maintaining security at the empirical layer for SPDI
4.20 Procedure for maintaining security at the syntactic layer for SPDI
4.21 Procedure for maintaining security at the semantic layer for SPDI
4.22 Procedure for maintaining security at the pragmatic layer for SPDI
4.23 Procedure for maintaining security at the social world layer
4.24 Service Level Agreement for outsourcing or insourcing of services for SPDI
4.25 SPDI Training programs for all levels in the organisation
69

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

T
it_amendment_act2008.pdf
N
otifications from Ministry of IT, www.mit.gov.in/content/notifications
C
OBIT 5, www.isaca.org/cobit
C
OBIT 5: Enabling Processes, www.isaca.org/cobit/Documents/COBIT-5-Enabling-Processes-Introduction.pdf
C
OBIT 5 Implementation, www.isaca.org/cobit/Documents/COBIT-5-Implementation-Introduction.pdf
C
OBIT 5 for Information Security, www.isaca.org/COBIT/Pages/info-sec.aspx
I SO/IEC 27001:2005, Information technologySecurity techniquesInformation security management

systemsRequirements
F
air Information Practices from OECD Guidelines governing the protection of privacy and transborder flow of personal
data, www.oecd.org
Annexure EFAQs
For comments, discussion and frequently asked questions, please refer to www.isaca.org/topic-india
70

10 1 1 252 9782

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

10 1 1 252 9782

Uploaded by

Copyright:

Available Formats

Securing Sensitive Personal

Securing Sensitive Personal Data or Information

Securing Sensitive Personal Data or Information

Subramaniam Vutha, B.Com, LLM, ACS, DTM

Securing Sensitive Personal Data or Information

Chapter 1. What is Personal Information?

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

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

Chapter 4. Meeting Stakeholders Needs for Securing SPDI

Stakeholders needs Enterprise goals IT-related goals Enabler goals

2. What does each chapter cover?

3. Who should read and use this book?

4. Why should you secure sensitive

You need to secure sensitive personal data because:

5. Which aspects of such compliance

6. Why should you read this book?

The Information Technology Act, 2000, www.mit.gov.in/sites/upload_files/dit/files/downloads/itact2000/itbill2000.pdf

Securing Sensitive Personal Data or Information

8. How should you use

Use this publication as a handy code of good practices guide for:

9. What are the supporting

Why Personal Information Is Important

Personal Information (PI)

Personally Identifiable Information (PII)

Securing Sensitive Personal Data or Information

Purpose of Defining SPDI

Why It Is Important to Secure SPDI

General Principles for Securing Personal Information

Use of COBIT 5 for Securing SPDI

Securing Sensitive Personal Data or Information

Chapter 2. Indian Sensitive Personal Data

Step-by-step Explanation of the IT Act

The IT Act provides for legal recognition for:

Securing Sensitive Personal Data or Information

Chapter 2. Indian Sensitive Personal Data

4 A. Is any public domain data or

(See proviso to Rule 3 of

5. What happens if the body corporate

(See Section 43 A of the IT Act.)

Securing Sensitive Personal Data or Information

Chapter 2. Indian Sensitive Personal Data

 ow do we get consent for

(See Rule 5 of the Information

A lawful purpose is:

(See Rule 5 [2] [a] of the

Securing Sensitive Personal Data or Information

Chapter 2. Indian Sensitive Personal Data

ISO/IEC 27001:2005, Information technologySecurity techniquesInformation security management systemsRequirements

Securing Sensitive Personal Data or Information

20. Is there a duty not to publish?

(See Rule 6 [3] of the Information

1. Do we have mechanisms in place to:

(See Rule 6 [4] of the Information

 hat are the rules for transfer

Chapter 2. Indian Sensitive Personal Data

The international standard ISO/IEC 27001:2005, Information technologySecurity techniquesInformation

(See Rules 8 [2] and 8 [3] of

Securing Sensitive Personal Data or Information

27. How will compensation be

Chapter 2. Indian Sensitive Personal Data

Securing Sensitive Personal Data or Information

Source: COBIT 5, figure 2

Securing Sensitive Personal Data or Information

4. Why should you secure sensitive

8. How should you use

9. What are the supporting

4 A. Is any public domain data or

5. What happens if the body corporate

ow do we get consent for

ISO/IEC 27001:2005, Information technologySecurity techniquesInformation security management systemsRequirements

1. Do we have mechanisms in place to:

hat are the rules for transfer

27. How will compensation be

6. What are the (control)

8. Am I running an efficient and

10. Do I have enough people

13. How do I improve business

14. Do IT projects fail to deliver

12. Is the information I am

11. How do I get assurance

4. How do I best build and

19. Are sufficient IT resources

22. Does IT support the

18. How much of the IT effort

21. Are the total IT effort and

17. What has been the average

20. How long does it take to

16. What concrete vital primary