Naavi.org

A Russian ransomware gang CLOp has reportedly been exploiting a zero day vulnerability in a secure file transfer software called MOVEit and has reportedly affected hundreds of businesses in UK and USA.

Moveit is a managed file transfer software product produced by Ipswitch,inc which encrypts files and uses FTP or SFTP protocols to transfer data. According to wikipedia, a stable release of the software is dated 2019. The program is used by many organizations including PWC, E& Y, BBC, Shell, British Airways, Boots, Zellis and several government agencies such as U.S. Department of Energy, the Louisiana Office of Motor Vehicles, the Oregon Department of Transportation, the Minnesota Department of Education, the Novia Scotia government etc.

It is surprising that the vulnerability remained undetected and unpatched showing the lack of security oversight in the software product industry worldwide. Though thousands of high profile companies used the software, it is surprising that no audit had brought out the security vulnerability.

The attack has rightly renewed the call for holding the software developers legally responsible for lack of “Reasonable Security”. Under the Indian law, if the software supplier contract is a “Service Contract”, the software company may be liable as an “Intermediary”.

If it is an outright sale, then the software developer may claim transfer of responsibility on the basis of “As is Where Is” sale contract. However reasonable disclosure of the product vulnerabilities or alternatively an access to code audit is essential for the software supplier to escape full liability as an “Intermediary” under ITA 2000.

Naavi has always advocated such a liability and as a measure of better security and it appears that Whitehouse’s National CyberSecurity Strategy has also called for similar measures.

Speaking on behalf of the software developers, Naavi has advocated that apart from the reasonable efforts at testing before a “Stable Release”, every developer should mandatorily run a “Bug Bounty Program” and try to continue the testing in the public space with a reward program implemented fairly. This is a compliance measure included in the now increasingly appreciated PDPCSI (Personal Data Protection Compliance Standard of India), a framework of compliance designed by Naavi and implemented by FDPPI in its certification audits.

We may also highlight that this software MOVEit may be classified as an “Automated Personal Data Processing Software” and hence use of the software was subject to regulations like GDPR. Compliance in such context required a DPIA by the user organization and a requirement of an assurance certificate from the licensing organization.

It is now the turn of GDPR supervisory authorities to question the users of MOVEit and demand payment of penalties for not conducting DPIA when they started using the software.

According to securityweek.com the company has now started releasing security patches which will apply necessary changes to Moveit transfer and Moveit Automation, the two products affected by the vulnerability.

One of the vulnerability patched is a SQL injection vulnerability that allows an unauthenticated attacker to gain unauthorized access to the MOVEit Transfer database. Using this vulnerability, an attacker could submit a crafted payload to a MOVEit Transfer application endpoint which could result in modification and disclosure of MOVEit database content.

The patches also covered multiple high-severity Progress MOVEit Transfer vulnerabilities that allowed authenticated attackers to gain unauthorized access to the MOVEit Transfer database. where by an attacker could submit a crafted payload to a MOVEit Transfer application endpoint which could result in modification and disclosure of MOVEit database content.

Security investigators in KROLL have reported details of the codes exploited by the hackers and indicate that over the course of approximately 14 minutes, threat actors were observed exploiting a MOVEIt web server, dropping a web shell, establishing connections to the web shell, and initiating automated data enumeration and exfiltration preparatory steps. They also noted that there were no active user sessions created in the table, no log entries and no unusual activity appearing within the MOVEit logs. At the end of the 14 minutes, a new threat actor IP address established a web shell connection and what followed for the next several hours were several thousand GET and POST requests which, when overlayed with the available firewall logging, indicated several large volumes of data being transferred to the new IP address.

Kroll observes that because of the exfiltration method used, it can be missed during initial forensic investigation. However the organizations need to carefully observe the GET and POST requests executed and if any uptick is observed, additional measures triggered to confirm the malicious activity.

The lessons that Privacy professionals should take from the incident are

a) Document an assurance from all software suppliers that they have undertaken reasonable measures of testing and the installed version is free from zero day vulnerabilities.

b) Conduct and document a DPIA when new software products/services are used

c) Initiate a “Exfiltration Watch” which observes any accelerated activity and raise alarms as a part of the Data Leak Prevention strategies.

Software developers need to revise their testing process to stand the test to be called “Reasonably rigorous” and support by continued bug bounty program”.

Buyers of software need to review the contracts to see if they have a Code review option or an indemnity against zero day vulnerabilities or at least an insurance back up.

Naavi

Comments welcome

Also Refer:

Bug Bounty Policy as part of Corporate Governance Responsibilities

various articles at naavi.org

More details on the attack

In the series of articles so far, we have discussed the Scope of ISMS under ISO 27001 as well as the Leadership requirements and some aspects of Planning.

In this article let us list out all the requirements specified under Clause 6 of the standard documentation related to “Planning”.

Under this clause, the document specifies

6.1: Actions to address risks and opportunities

6.2: Information Security objectives and planning to achieve them

6.3: Planning of changes

Under 6.1, the organization shall make an assessment of the risk, establish a risk acceptance criteria, how the risks can be addressed. Planning should also cover actions required for continual improvement and also address “Opportunities”. The mention of “opportunities” indicates that we need to plan with a “Risk-Reward” perspective so that implementation of ISMS does not adversely conflict with the business development. For treating the risk, efforts shall be made to make use of the controls suggested in Annexe A. Apart from detailed planning with responsibility assignment, resources etc, the ISMS needs to recognize the possibility of changes and how they are to be handled.

In providing “Support” for the planned activities, it is necessary to ensure that the organization shall determine the competence of the people assigned with specific roles and retain appropriate documented information as evidence of competence. It is also necessary to build appropriate awareness across the organization with appropriate internal and external communication policies. The activities shall be properly documented and updated and an appropriate document control system shall be adopted so that reference would be facilitated.

Under clause 8 on “Operation”, the standard document requires an operational planning and control system to be developed including the schedule for periodical changes.

It is interesting to note that clause 9 of the standard speaks about the need for measuring the effectiveness of the ISMS implementation. Most of the time this is ignored in implementation since there is no clear template for the same.

In this context we may appreciate that PDPCSI specifies the Data Trust Score (DTS) system and FDPPI has developed a specific suggested mechanism for evaluating the maturity of PDPCMS through a DTS number. A similar approach can be extended to the ISMS also if the DPCMS is used as a framework.

ISO 27001:2022 also requires an established internal audit programme as well as a management review and corrective action.

Lastly the standard document specifies that the ISMS must focus on “Continual Improvement” .

The 10 clauses of the standard document are supported by the 93 controls in the Annexe A, which has been drawn from ISO 27002 which needs to be referred for detailed explanation of any of the Annexe items.

We shall try to review these 93 control items in subsequent articles.

Naavi

We are presenting a series of articles in this series to spread the awareness and understanding of ISO 27001, ISO 27701 and PDPCSI.

ISO 27001 is a certifiable standard while ISO 27701 is a requirement which can be certified only along with ISO 27001. ISO 27001 refers to ISMS where as ISO 27701 refers to PIMS.

On the other hand, PDPCSI (Personal Data Protection Compliance Standard of India) is a framework for Personal Data Protection by organizations in India in compliance with the legal standards such as Information Technology Act 2000/8 and the upcoming DPDPB 2023. PDPCSI refers to PDPCMS which is the personal data protection compliance management system.

Since PDPCMS/PDPCSI is focussed only on personal data, it compares directly with ISO 27701 instead of ISO 27001. However, since ISO 27701 cannot be implemented without ISO 27001 which is a foundation standard, an understanding of ISO 27001 will help us understand PDPCSI better. Also ISO 27001 is relevant for the preservation of CIA of personal data within PDPCSI where Model Implementation Specifications (MIS) 31-50 address different aspects of security under the CIA concept. Hence there is some comparison between PDPCSI and ISO 27001 which may be relevant.

Readers may kindly appreciate the context in which this series of articles have been presented and read all articles in the series besides information available on PDPCSI.

In this article let us continue our discussion on ISO 27001 and discuss the recommended Governance Structure to meet the objectives of ISO 27001:2022.

Clause 5 of ISO 27001 on leadership lists out the following requirements as “demonstration of leadership and Commitment” of an organization.

a) ensuring the information security policy and the information security objectives are established and are compatible with the strategic direction of the organization;

b) ensuring the integration of the information security management system requirements into the organization’s processes;

c) ensuring that the resources needed for the information security management system are available;

d) communicating the importance of effective information security management and of conforming to the information security management system requirements;

e) ensuring that the information security management system achieves its intended outcome(s);

f) directing and supporting persons to contribute to the effectiveness of the information security management system;

g) promoting continual improvement; and

h) supporting other relevant management roles to demonstrate their leadership as it applies to their areas of responsibility.

Under Clause 5.3, the standard prescribes that

Top management shall assign the responsibility and authority for:

a) ensuring that the information security management system conforms to the requirements of this document;

b) reporting on the performance of the information security management system to top management.

We can interpret the above requirements as projecting a need of a designated Information Security Manager (ISM) or Chief Information Security Officer (CISO) so that there is accountability for implementation and reporting to the top management.

Even ISO 27701 does not clearly specify the need of a DPO which is mandatory in many laws for certain category of implementers.

Under PDPCSI which requires compliance of law directly, it is essential to define the role of the implementing organization and the mandatory need for a designated role of a Data Protection Officer. It suggests the three levels of governance Governance Committee, DPO and Process Level Data Controllers besides a “Privacy Officer” in a large organization.

As a recommendation, most experienced auditors recommend that under ISO 27001 there shall be a “CISO” or “ISM” who will be responsible for implementation and monitoring as well as internal audit. It is common for organizations to use the assistance of external consultants when ISO 27001 is implemented for the first time and also get Certified by an independent auditor. Maintenance is done by the CISO and the certification audit is renewed from time to time normally after 3 years.

Naavi suggests that the Governance system

1. A Governance Committee (Steering Committee) to provide overall guidance
2. CISO to be the designated person responsible for coordinating the entire activity
3. Support team which can be called the IS organization.

Though not specified by most ISO auditors, Naavi suggests that it is necessary to identify the following support roles.

a) Data Custodians for each data store

b) Controllers who monitor incoming data and data disclosures

c) Controllers who monitor the different data transformation processes within the organization.

If an organization has multiple locations and business divisions, it would be better if Information Security Champions are identified at each of the divisions and the locations to assist the CISO as a central coordinator.

The Steering committee will have representation of all stake holders within the organization and will ensure that there is cooperation of all stakeholders in the implementation on a continuing basis.

The organization should not project ISMS as the responsibility of only the IT department since it is more an organizational responsibility than the IT responsibility. The “Security Culture” should pervade the entire organization.

Some of these suggestions cannot be directly indicated in a framework document and has to suggested by experienced consultants.

We shall discuss the Annex A controls individually which provides the high level indication of what is expected as a “Control” within which we shall draw inferences on not only the suggested Governance Structure but on other aspects as well.

Naavi

In the previous article we discussed the need for creating Asset Inventory as part of the Context setting.

In the process, we identified four different aspects such as “Data Storage Points”, “Data Collection Points”, Data Processing Points” and “Data Disclosure Points” to be identified in a network to create the Asset inventory. We also discussed the concept of “Data Valuation”. We did not stop at looking at Data Value from the abstract concept of “Everything that assists the business has a value” but went on to underscore the need for assigning the rupee value of the asset that can be brought into the balance sheet if need be.

If we want the CFO to sanction a budget for ISMS, then he has to be convinced that there is an X crores worth of data that needs to be protected and the ISMS will mitigate the risk of loss or erosion of this X Crore asset value. For this purpose assessing the rupee value of the asset is important and Naavi’s DVSI (Data Value Standard of India) tries to suggest some methodology for the purpose particularly for the Personal data.

In the context of ISO 27001, the valuation in rupee terms is relevant since if there is a ransomware attack, the hacker would ask for a ransom based on his estimated value of the data. His valuation of data may either be based on the market value for the data in the Dark Web or the amount upto which the organization would pay to protect its reputation damage or save on cost of reconstruction of data. For the organization therefore “Opportunity Cost” and ” potential damage” is a measure of value. For the hacker the “Realisable market value” is a measure of its value.

If the ISMS manager wants to assign a value it may depend on the nature of the activity of the organization. If Data is a raw material in the business of the Company and gets converted into finished goods at the end of a process (Eg Data Analytics Company) then the value can be computed on the basis of the accumulated cost from generation of the data to its current status in the life cycle moderated by revaluation based on the market value. If data is only a tool of business, its value is based on the cost of creation only.

Whatever be the methodology used for valuation and whether it is only an approximation for the purpose of a “Note to the Accounts” or to be incorporated in the balance sheet as a “Contra Item”, there is a need to first classify the information into different value buckets.

In the ISMS context, data classification is based on the “Risk Potential” and hence it is common to observe a classification as “Confidential”, “Restricted”, “Internal” and “Public”.

Some examples of classification on this basis are

• Confidential: This level of classification applies to information that could cause serious harm to the organization if it were disclosed to unauthorized individuals. Examples of confidential information include trade secrets, financial data, and customer information.
• Restricted: This level of classification applies to information that could cause some harm to the organization if it were disclosed to unauthorized individuals. Examples of restricted information include employee records, marketing plans, and product development information.
• Internal: This level of classification applies to information that is not confidential or restricted, but that should not be disclosed to the public. Examples of internal information include employee training materials, meeting minutes, and financial reports.
• Public: This level of classification applies to information that is not confidential, restricted, or internal. Examples of public information include press releases, product brochures, and website content.

On the other hand, a PII classification has to be done under scales based on the “Sensitivity” . For examples as against a general categorization of “Personal Data”, one can create a category “Sensitive Personal Data” or “Critical Personal Data” based on different risk profiles of the data itself.

Hence Data has to be first classified as “Personal” and “Non Personal”, and then Non Personal Data should be classified based on the Confidential, Restricted, Internal and Public criteria and Personal data classified as is relevant for the applicable law.

PDPCSI or any other Privacy frameworks therefore use a classification different from the ISO 27001. PDPCSI goes a step further than other frameworks since it recommends sensitivity based classification on whether the data belongs to the Employees or others, Minors or Adults , Deceased individuals or Living Individuals etc.

The classification suggested under A 5.12 of ISO 27001 states….

“Information shall be classified according to the information security needs of the organization based on confidentiality, integrity, availability and relevant interested party requirements.”

ISO 27701:2019 refers to EU GDPR in its introductory reference but does not provide clear guidelines within the document. Hence classification based on GDPR will drive ISO 27701.

On the other hand, PDPCSI pitches the classification requirement to be “Compliance Based” and states as follows

“The organization shall classify  data based on nature of personal data, its sensitivity, type of data subject, whether   minor data or employee data is involved,   the country of origin, etc”

Thus the Context setting includes creation of a data inventory along with the classification.

Apart from creating an “Inventory of Data” where it lies in storage, it is also necessary to identify the “Process Inventory” which lists all the processes where the input data and output data is different. The modification of data that occurs within a process is to be captured for risk assessment (eg Automated Decision making risks). This will also assist in designating “Process Controllers”, “Consent Controllers”, “Disclosure Regulators” and “Data Custodians” who are all different organs of the ISMS Manager.

To further take control of the Data inventory, it is necessary to identify the Data Input points and Data Disclosure points so that the Inventory of data in storage and data in process can be managed from the point of view of CIA principles. Data Disclosure in this context is mainly to the external parties since internal data disclosure gets merged with transfer of data from one process to another as an input data into the next process.

To summarize, after setting the context for ISMS, we should have a proper understanding of the classified data based on an acceptable criteria. We should know where the data is stored, where all they are processed, which are the input and exit points to be secured.

In the Planning stage these are important steps that needs to be completed before we go further into the creation of the ISMS Governance structure. Then we go into creation of policy documents, then to implementation of controls, then to review and correction. These are the steps that ISMS has to go through .

(To Be Continued)

Naavi

Before an organization sets about to establish an ISMS or an auditor starts an ISO 27001 audit, it is essential to understand and set the ‘Context’ in which the activity needs to be planned and implemented.

By ‘Context’ we mean the internal and external issues that reflect the constraints for the activity of the organization.

To the extent these constraints are manageable, they can be addressed as part of the suggested business policy changes that can accompany the setting up of the ISMS. To the extent the constraints are internal and affect the ISMS risks, they need to be mitigated as a part of the risk management policy. To the extent the constraints are not controllable, they need to be accepted and risks arising thereof become absorbed risks.

Most of the time the role of an auditor arises in an existing organization which already has established a vision and mission and has a top management Governance system tuned to business objectives. The IS objectives are to be integrated into this structure. In the process it may cause disruptions of existing systems and hierarchy of decision making which has to be recognized as an “Implementation Risk” and has to be handled with finesse.

This is the toughest part of the activity of ISMS and is often addressed as the challenge of getting a Buy-In by the top management. A successful ISMS auditor needs to therefore have the skills of communication and persuasion required to get the plan accepted and resources sanctioned.

Most often, the ISMS activity in an organization is triggered because the market forces dictate them. Some clients would have raised a query “Are you ISO 27001 compliant? or Are you GDPR Compliant?”, or “Are you ITA 2008 Compliant?”, or “Are you DPDPB 2022/23 compliant?” etc.

The marketing person might have given a feedback that they may lose a prospective contract because of not being able to provide an assurance to the client about the status of Information Security/Privacy Protection in their company.

At this time, the Company needs to decide on what is required for them in the given context and chose if they have to go for ISO27001 or DPDPB 2022 or GDPR as a framework of designing its activity.

If a Company is operating in India entirely for the Indian customers, it has more value for ITA 2008 compliance than GDPR certification. If a company is interested in Privacy more than IS, priority has to be for GDPR than ISO 27001. In India ITA 2000/8 today is both an IS law as well as privacy law. The company has to determine this at the time it sets the context.

A GDPR or DPDPB 2022 framework may be recognized as a “Privacy Compliance” requirement and not an ISMS per-se. On the other hand ISO 27001 is an ISMS per-se and when associated with ISO 27701 adds Privacy also. However, a GDPR or DPDPB 2022 does address CIA principles of information security within the “Personal Information” domain and hence ISO 27001 is still relevant for implementation of GDPR or DPDPB. If the same principles are extended to Non Personal Data, a DPDPB compliant organization can be also compliant with ISO 27001 standards as a whole.

When we plan an ISMS under ISO 27001, we need to understand that the context has to take into account that there is a law in India on Information Security called Information Technology Act 2000/8 (ITA 2000/8) and there will be consequences if the ISMS does not meet the requirements of ITA 2000/8. Hence the need to understand the legal environment and ensure that the ISMS is in sync with the ITA 2000/8 is an essential part of the context building.

Available resources of a Company obviously is a constraint which has to be factored into the planning since an SME with a turnover of Rs 10 crores cannot be expected to spend as much money as an MNC with a turnover of Rs 1000 crores. A start up with 20 employees cannot plan an ISMS like an organization with 20000 employees. Hence the ISMS planner/auditor needs to be flexible and this gets reflected in the SOA (Statement of Applicability) or the Implementation Charter (PDPSI specification).

Apart from the legal compulsion which if not complied with, may come with heavy penalties, it is necessary for the management to be convinced about the need for the ISMS or DPCMS (Data Protection Compliance Management System). The best way to achieve this is to present the ISMS requirement as a “Business Objective”. It is for this reason that the ISMS planning has to take into account the needs of the CMO, CFO and the CEO as much as it is an initiative of the CTO to reduce the risk of data breach and meeting the risks of a Cyber attack.

This “Management perspective” of ISMS has to be addressed by linking the ISMS need to the business objective. Unless an organization is a philanthropic organization, management cannot disassociate itself from the profit motive. Hence it will be impractical if we as ISMS planners donot understand the needs of the management to make money for the Company. Hence the views of the CMO/CFO/CEO needs to be adequately respected and their acceptance to any ISMS proposal is a necessity.

Hence it is always better to start the ISMS activity with the development of an Information Asset Inventory and making the management realize the value of the assets they manage and the consequences of not securing these valuable assets. Developing an inventory of Data Assets mean identifying the Data Storage points, Data Collection Points and Data Processing Points. It is better to add the Data Disclosure points also to this “Data Mapping” exercise so that the lifecycle of data in the organization is properly understood for determining the context.

ISO 27001 may not directly refer to any controls that direct them to financially value the information assets while PDPCMS based on PDPCSI does mandate a thought on Data Valuation as a part of brining the visibility of the asset value to the top management. Similarly PDPCMS also takes into account the need for “Monetization” of personal data within the legal permissions by suggesting appropriate policies for “Profiling”, “Monetization” etc.

When a visionary ISO 27001 implementer interprets the “Context” under clause 4, he may include the “Risk Analysis” based on ISO 31000 and may arrive at the same conclusion that PDPCMS arrives at regarding the need for Data Asset Valuation. But as a framework, a majority of the implementers of ISO 27001 may miss these requirements.

It is for these reasons we say that PDPCSI is an improvement over existing frameworks such as ISO 27001 (with ISO 27701 combined).

It may take time for the market to realize this but it will happen over a period of time as PDPCMS becomes more and more common in implementation.

Naavi

ISO 27001:2022 adopts a structure of presenting the requirements through the main document that consists of 10 clauses and the Annexe A which indicates 93 controls.

In comparison, PDPSI adopts 12 Standards and 50 Model Implementation Specifications.

The first three clauses of ISO 27001 cover the scope, Normative references and the Terms and definitions. More critical aspects of implementation are covered by the clauses 4 to 10 namely

4: Context of the Organization

5: Leadership

6:Planning

7: Support

8: Operation

9: Performance Evaluation

10: Improvement.

The structure of the clauses follow the PDCA approach of Plan, Do, Check and Act cycle.

Clause 1 specifies the scope of the document as specifying the requirements for establishing, implementing, maintaining and continually improving an information security management system (ISMS) within the context of an organization. The requirements for assessment and treatment of IS risks are also covered. The scope does make a mention that excluding any part of the requirements specified in clauses 4 to 10 is not acceptable. But this has to be seen along with the “Statement of Applicability” under clause 6.1.3 (d) which allows omission of certain controls based on a justification.

PDPCSI defines its scope as the compliance of laws related to Personal Data Protection and includes the word “Compliance” in the title itself. The target law that a PDPCSI system has to address depends on the “Data Set”.

Hence if an organisation has multiple country data like GDPR data and Indian data, PDPCSI implementation may require application of one set of controls for GDPR data and another set of controls for Indian personal data.

This is achieved through appropriate “Classification” of information with a tag of “Applicable Jurisdiction”. This approach enables PDPCSI to be called a “Unified Framework”.

ISO avoids this difficulty by stating that the requirements are “Generic” and not specific to any sector. But ISO creates multiple standards for different sectors.

The version of PDPCSI applied to Non Personal Data which we may refer some times as “Non Personal Data Compliance Standard of India (NPD-CSI) will similarly focus on jurisdiction of law and NPD-CSI for Indian context will be compliant with ITA 2000/8. This framework titled as IISF 309 was one of the first such frameworks suggested by Naavi way back in 2009 along with three levels of maturity as Level I, II and III. This is now being merged with the concept of DTS and brought under NPD-CSI.

PDPCSI also refers to “Deviation Justification Document” and an “Implementation Charter” which provides flexibility to logically exclude certain Model Implementation Specifications (MIS) and arrive at a set of Adopted Implementation Specifications. (AIS). The PDPCSI supported DTS calculation is done on the basis of MIS but the Certification of Compliance is provided on the AIS and the Implementation Charter approved by the management on the basis of their Risk absorption policy.

DTS represents the maturity of an organisation in implementation and hence adds value to the framework.

PDPCSI therefore provides the flexibility for the management to tailor the framework for different sizes of the organization and different sectors.

ISO 27001 refers to ISO 27000 in its normative reference while PDPSI is a standalone framework.

However we may pick up ISO 27701 (A requirement and not a certifiable standard) for comparison with PDPCSI as it is a privacy framework.

ISO 27701 is presented as an extension of ISO 27001 and hence is dependent completely on ISO 27001. It defines a category of PIMS as an extension of ISMS but does not make distinction of type of organization or the sectoral differences.

In the description of the structure of the document, ISO 27701 states that “This is a sector-specific document related to ISO 27001 and 27002”. It appears to identify PII as a “Sector” by itself. The approach stems from the focus on “Data” more than the “Person behind data” which is necessary for Privacy discussions.

Some of the sectoral requirements are addressed through separate standard definitions making ISO 27701 a maze of multiple standard implementations. Compliance will always be better if it is simple.

If we make Compliance of one standard dependent on another and another as a chain, it will make it difficult for the complying organization to maintain the compliance over a time. PDPCSI tries to achieve simplification by making it a “Unified Model” and enabling flexibility to be achieved at the implementation level.

For Example a consent document under PDPCSI-India may conform to DPDPB 2022 while a similar document under GDPR may conform to GDPR requirements while the standard and the model implementation specification may remain the same for both. By adopting this process PDPCSI avoids duplication of standard to some extent. For the same reason PDPCSI leaves it to the consultants to develop their own templates and not make templates part of the MIS.

The 12 standards of PDPCSI are as follows:

1	Applicable Law
2	Governance Structure
3	Risk Mitigation Charter
4	Compliance By Design
5	Compliance oriented Data Classification
6	Distributed Responsibility
7	Communication with Stakeholders
8	Technical Controls
9	Policy Controls
10	Compliance Culture
11	Certification capability
12	Measurability

The Standards mentioned in PDPCSI are explained in greater detail under the Implementation specifications and some of the title headings may repeat under the MIS with specific responsibility assigned to different divisions.

We have presented the 12 standards of PDPCSI here for comparison with the clauses 1-10 of ISO 27001 only.

The difference in the approach between the the two frameworks is that ISO 27001 tries to follow the PDCA through the 10 clauses. PDPCSI on the other hand expects PDCA in each of the MIS implementations in addition to covering “Audit” as one of the controls. Even the MIS on audit would be subjected to PDCA process.

The four themes of the Annex A controls as against 14 earlier is closer to the PDPCSI approach where 5 responsibility centers were identified for implementing 50 MIS.

ISO 27001 is however more oriented to four processes whereas PDPCSI recognises five responsibility centers.

In a future article we shall present the mapping of ISO 27001 to PDPCSI and identify how may are similar and how many are different.

…Let us continue our discussion in the next article…

Naavi