Updates from March, 2016

  • ISO 27001 Case Study – How Coral made a Robotics Provider achieve certification 

    How Coral made a robotics designer to achieve ISO 27001 compliance

    Business

    The company provides robotics design, and development including production of robots for commercial and defence service providers.

    Here we explain the 5-phase approach that we followed for making the organisation ISO 27001 compliant.

    Phase 1 – Gap Analysis/Risk Assessment/Maturity of Current ISO 27001 Processes

    Phase 2 – Skill Transfer including documentation

    Phase 3 – ISMS Performance Tracking

    Phase 4 – Internal Audit

    Phase 5 – External Audit

    Phase 1 – Gap Analysis/Risk Assessment/Maturity of Current ISO 27001 Processes

    We started with meeting top management with their expectation of ISMS including what they considered as most sensitive information that needs protection. We were surprised to see that what they considered was very different from what head of departments considered as most important piece of information that requires protection.

    In this phase we also identified their different forms of assets using our evolved asset master template. Once the assets were identified and focused on business transactions performed by business and their different teams.

    This resulted us in identifying

    • All forms of assets
    • All forms of information
    • All risks and vulnerabilities
    • Process Maturity of each of the 114 controls

    We applied our evolved risk assessment methodology that included ISO 31000 requirements steps.

    Phase 2 – Skill Transfer including documentation

    Each team underwent a detail understand of their responsibility for security compliance from an ISO 270001 perspective. We defined and communicated a strategy – where each team would owned a portion of applicable 114 controls.

    Each team underwent a set of tasks that involved the following deliverables:

    • Skill Transfer – they learnt how to do security tasks that they did not perform earlier
    • Documentation – There were several policies and procedures created that involved ISO 27001 Management System controls (Clause 4 to 10), applicable 114 controls. They were involved in reviewing every document before accepting.
    • Communication – Each team communicated the impact of the changes to their nature of work, including communication to other effected teams and individuals.
    • Metrics – An agreed threshold of performance for a control and security transaction.

    Phase 3 – ISMS Performance Tracking

    This phase is of reporting the allocated ISMS transactions/processes with their level of performance. This phase is the outcome of the previous phase where each team agreed to report their area of allocated security compliance.

    We acted as a reviewer of performance and gave them suggestions, including compliments – where they performed the transactions in the way it was desired.

    We found good progress in the way they now understood the requirements.

    Phase 4 – Internal Audit

    An independent consultant from our team who was not involved in the previous phases performed an audit, giving a simulation of external audit. In this phase the auditor performed audit tasks that involved the followings:

    • Determining most information assets
    • Design, documentation in line with the ISO 27001 standard
    • Awareness of personnel on common and team specific procedures
    • Management participation on the whole program including reaction of performance reports

    The internal auditor submitted a detail report that shows strengths and weaknesses, including maturity of the individual ISO 27001 114 control requirements.

    Phase 5 – External Audit

    Client chose a suitable certification body that fit their budget and brand expectations. The external body audit team consisted of two team members.

    Stage 1 – Documentation audit was performed to verify the documented requirements of the standard. The auditor submitted the report with suggestions and improvements, which we modified.

    Stage 2 – Implementation audit was focused on verifying the controls. This involves meeting all teams including Information Technology, IT security, physical security, application development lifecycle, legal and compliance team. The audit team identified few opportunities for improvement, which were addressed by the customer team with our support.

    The company was successfully certified in ISO 27001 – 2013. The fruits of compliance includes a proactive approach to ISMS.

    Business Benefit

    The company acknowledges that ‘security is implemented in everything that they do’.

    Hope you enjoyed reading the article!

    If you wish to implement ISO 27001-2013 in your organisation, please write to us at roadmap@www.coralesecure.com.

     
  • Roadmap After ISO 27001 

    You are currently ISO 27001, and now are looking forward to mature your risk management processes.

     

    In this article, we wish to highlight what are the next possible standards, and what benefit you can plan to achieve should you decide to pursue them. In this we highlight the following standards:

    ISO 31000

    ISO 20000

    ISO 22301

    SSAE 16/ISAE 3402 – SOC 2

    COBIT 5

    Here is a brief roadmap of what each of these standards means, and what enterprise value you can gain:

    ISO 31000 – Enterprise Risk Management

    If you are currently ISO 27001 – 2013, you have tested the benefits of enterprise ‘information’ risk, now it is time to take this experience to all areas of business. If you are in that mindset, consider ISO 31000.

    ISO 20000  – IT Service Management System

    With ISO 27001 – 2013, you have designed and implemented security processes. Did you know that with ISO 20000, you can further improve your overall IT service delivery, by bringing more speed to IT service delivery? Processes such as service level management, service catalogue, configuration management database, Known error database, you can make IT more resilient, more aligned to business strategy.

    ISO 22301 – Business Continuity Management System

    With ISO 27001, you have ‘preventive’ controls in place. You might have also created restoration plans for IT. What about the whole business? With ISO 22301, you can implement restoration plan for whole business.

    SSAE 16/ISAE 3402 – Type 1, Type 2

    With ISO 27001 you have security processes in place. If you plan to enter US/European market to a public listed entity, that will not be good enough, you would need to demonstrate security processes for a period of 6 months, attested by a CPA firm. This will enable your entry to the largest accounts.

    COBIT 5

    With ISO 27001 you have implemented 5 of the 27 IT governance/management processes. With COBIT 5 you can align Business strategy with IT strategy.

     

    If you have any other standard or benchmark that come to your mind, and would like to know how your current investment in ISO 27001, can help you align, do write to us.

     

    Do not hesitate to call or write to us if you wish to know more, and would like to have a detail understanding of each one of these.

     

     
  • Business Continuity tabletop exercise – who to involve? 

    The tabletop exercise involves involving each individual whose responsibility is defined and documented in your business continuity plan. The days that you spent in creating the plan should be completely wasted – unless each role and individual named agrees to the content.

    Top Management – Even if you cannot get the CEO, involve someone from your core customer facing team. The role will check if the continuity fulfils customer or core operations in case of restoration.

    Business continuity Manager – This role has the complete oversight of how fast the enterprise needs to be responding to each documented plan. Involving him/her ensures that the outcome of the business continuity plan is achieved in line with business objectives.

    Assuming you have plans to manage site outage, technology outage, vendor outage and people outage, involve both process and support teams to be a part of this exercise.

    Information Technology – Whether it is hot site/warm site or cold site strategy, individuals should acknowledge their ability to restore within the recovery point objectives(RPO), in line with return time objective (RTO).

    Human Resources – If your people outage involves cross training or replacement of existing employees to do a specific task, then the head of those teams should agree and acknowledge that the replaced employee will be able to do the desired work.

    Procurement – If your vendor outage strategy involves seeking an alternate service provider, the procurement team and the respective team whose services will be effected, should agree and acknowledge the alternative plan.

    Physical Security – The physical security team should be able acknowledge the availability of the alternate site and its readiness in case of a site outage as defined in the plan.

    Crisis Management Team(CMT) - CMT Members are the ones who invoke the continuity plans. They should understand each of the outage scenarios, the human element of crisis, and the outage plans. They know that it takes time, and resources to invoke these plans, and there role is to manage the human part of the process.

    Taking Feedback

    Ask questions to members attending the session – are you now more aware of the business continuity or your own responsibility? If the answer is Yes, half of the battle is won. Organisationally, you are now prepared for the next maturity level of continuity – which can be a combination of simulation test or a full blow one.

    Documenting Results

    All the teams participating should give a formal feedback about the outcome of the test, and their feedbacks should be documented for improving your overall continuity plan.

    If your business continuity plan is at version 1 – it is perhaps that it has never been read and reviewed. It is highly unlikely that post a formal tabletop exercise it will remain at version 1.

    Hope it helps!

     
  • ISO 27001 2013 migration roadmap 

    Your organization is  currently ISO 27001 2005 certified and looking for direction for ISO 27001 2013 up-gradation?

    Look no further! Here are some of the key steps you need to take to migrate to the new standard:

    In a previous blog we have mentioned the key differences between ISO 27001 2005 and 2013 version.

    Step 1 – You need information security context register or any other similar name that lists organization’s key strategic issues, risk and external and internal requirements for information security. In a way this document is an input the selection of your scope. What this means is that if you are the security manager, ensure information security is aligned with business objective, and that it leads to  selection of the right scope for ISO 27001 certification.

    Step 2 – ISO 27001 114 control gap analysis. This will result in identifying additional security controls that are applicable to your business and which requires to implemented. Controls such as security in project management is definitely something new in the new ISO 27001 2013 standard. Your gap analysis will show the additional controls that need to be implemented. There are nearly 15 such new controls that requires implementation.

    Step 3 – Implement the identified gaps.  This would involve policy writing skills, training and seeking records from respective teams who have the responsibility of this implementation.

    Step 4 – The new standard enforces the need for ‘risk ownership’, ‘communication’, and ‘accountability’. Establish these processes based on how you understand these terms. One such approach is to divide the statement of applicability (SOA) controls between organisational teams, and call them as control/risk owners.

    Step 5 – Security Performance dashboard is an additional requirement which needs to be implemented. The reporting enforces a higher degree of ownership among teams guarding the organization.

    Step 6 – Completing key procedural documentation in line with the ISO 27001 2013 requirement. An example could be writing the ISMS Manual in line with the standard requirement.

    Step 7 – Internal Audit. This will ensure that the old and new policies are implemented successfully.

    Step 8 – Management Review. If there are no major findings in internal audit go ahead and apply for an upgrade.

    Attempt is made to make the ISO 27001 2013 migration simplistic.

    Organization complexities such as number of locations, technology, vendor complexities, security compliance responsibilities, lack of policy writing skills, may result in delay in migration.

    Hope this helps!

     
  • Security in Project Management 

    One of the new requirements in ISO 27001 2013 is considering security in project management. The standard clause is as follows:

    “A.6.1.5 – Information security in project management  – Information security shall be addressed in project management, regardless of the type of the project”

    Source: ISO 27001-2013

    The implication of this clause applies to all types of projects and not simply ‘IT’ projects. This can be also be interpreted as security ‘of the project, by the project and for the project’.

    In any organisation there are several business units and teams with multiple focus areas working in unison to fulfil business objectives. Depending on the type of business your departments can be core customer facing services, revenue generating services, manufacturing, Information Technology, application development, Physical security, Human resources, legal and Finance department(not exhaustive). The work ‘project’ has different meaning to each of them.

    How to implement?

    In order to implement this clause organisations can take several approaches.

    One approach is to involve security manager (if you have one) in each and every project. This way every time a team conceptualises a project – the security manager is involved in assessment and articulation of security requirement.

    The other approach is to help and make managers trained on security requirement analysis as part of any project requirement.

    Irrespective of who or how an organisation implements this, the ability to correlate with one or more of the ISO 27001 114 controls should be understood. A direct question can be – ‘does the project need additional security to be implemented’? A simplistic view could be physical, technical, human resource or procedural requirements. A more complex view such as product implementation or an application development may require more step by step documentation of issues.

    The process implementation is evident when teams managing projects are able to articulate there security requirements which will take the form people, process or technology changes.

    If the clause is implemented correctly this will address security at the design phase. This will also minimise (if not completely eliminate) security as an afterthought.

    Hope this help!

     
  • Preliminary Cybersecurity framework released by NIST to protect critical infrastructure 

    What is Critical infrastructure?

    Critical Infrastructure is defined as any system and assets, whether physical or virtual, so vital to the United States (and can be interpreted for any country) that the incapacity or destruction of such systems and assets would have a debilitating impact on cybersecurity, national economic security, national public health or safety, or any combination of those matters.

    The critical infrastructure community includes public and private owners and operators, and other supporting entities that play a role in securing the Nation’s infrastructure. Each sector performs critical functions that are supported by information technology (IT), industrial control systems (ICS) and, in many cases, both IT and ICS.To manage cybersecurity risks, a clear understanding of the security challenges and considerations specific to IT and ICS is required.

    (Source: NIST)

    What is the framework all about?

    The Framework provides a common language for expressing, understanding, and managing cybersecurity risk, both internally and externally. The Framework can be used to help identify and prioritize actions for reducing cybersecurity risk and is a tool for aligning policy, business, and technological approaches to managing that risk. Different types of entities — including sectors, organizations, and associations — can use the Framework for different means, including the creation of common Profiles.

    How is this relevant to your organization?

    If you have critical infrastructure this is definitely for you.

    Every other organization can use the document (in its spirit) to associate the core framework to its existing security framework. The document provides a easy framework for Identify, Protect, Detect, Respond, Recover any core infrastructure.

    What is there for the security professional/CISO/ISMS Managers?

    The use of multiple standards – ISO 27001, NIST SP – 800-53,  COBIT, ISA 99.02.01 shows the depth of the document.

    Use the document to enhance your security posture. Use the Core framework and references for benchmarking existing security resiliences. It is a worthwhile effort.

    Download and read the document here – http://www.nist.gov/itl/cybersecurity-102213.cfm

     
  • Difference between ISO 27001: 2013 and ISO 27001:2005 

    ISO 27001: 2013 was released in September 2013

    Here are some of the high-impact changes:

    Change 1 – Standard is closer to enterprise risk management. The fact that information protection cannot remain aloof from organisation risk is well articulated in the new standard and is reflected in almost each management section clauses.

    Change 2 – There is an insistence on understanding information from a business perspective. References of enterprise ‘context’ in the new standard means that you see information from a business success or failure. Equally important is identification of external and internal issues in the success and failure of information security management.

    Change 3 – Scope definition is derived from organisation context rather than merely  a physical or a logical boundary. In the iso 27001 – 2005  standard you could chose a subset of the organisation as a scope (such as Information technology team) but in the new standard merely picking up a team for scope may be difficult as thus has to be aligned with business strategy. Leaving a strategic team facing customer may not therefore be easy and therefore MUST be included in the scope statement.

    Change 4 – Replacement of ‘Management commitment’ with ‘ Leadership’ – again an alignment with ISO 31000. In the past certain organizations have has CIOs signing the information security policy, this would be a thing of the past with the new standard.

    Change 5 – Risk assessment and risk treatment – the foundation of the subject – are clearer, elaborate and more objective. A section of information security objectives is very specific:

    ‘When planning how to achieve its information security objectives, the organization shall determine:

    what will be done
    what resources will be required
    who will be responsible
    when it will be completed
    how the results will be evaluated

    Change 6 – clause 9 – performance evaluation covers three essential topics, namely

    9.1 Monitoring, measurement, analysis and evaluation
    9.2 Internal audit
    9.3 Management review

    The alignment of this three issues is unique and gives more teeth to the implementation. For clause 9.1 the organisation needs to define what they need to measure and monitor as the management system level. Clause 9.2 – internal audit then focuses on those specific measurements, and clause 9.3 – management review is further aligned to review the performance based on the  audit results.

    Change 7 – Changes in domains, control objectives and detail controls

    In Annex A there will be 14 domains, 35 control objectives and 114 detail controls. The number of domains have increased however the total number of controls have reduced, the latter is an optimisation effort. The grouping of earlier clauses seems to make a lot more sense.

    Some of the main clauses which are either new or are more specific in the new standard:

    A.6.1.4 Information security in project management – this is a new clause, consider security every time you do a project;
    A.6.2.1 Mobile device policy – more specific in ISO 27001: 2013 compared to ISO 27001: 2005
    A.8.3.3 Physical media transfer – more specific in ISO 27001: 2013 compared to ISO 27001: 2005
    A.9.2.1 User registration and de-registration – more specific in ISO 27001: 2013
    A.9.2.3 Management of secret authentication information of users – this focuses on handling sensitive authentication data such as a password
    A.9.2.5 Removal or adjustment of access rights – considers ‘adjustment’ of access
    A.9.3.1 Use of secret authentication information – insistence on a procedure and awareness
    A.9.4.4 Use of privileged utility programs – new name to the older clauses ‘use of system utilities’ in the previous standard
    A.13.2.1 Information transfer policies and procedures – new name to the older clause ‘policy on exchange of information’
    A.14.1.1 Security requirements analysis and specification – more elaborate clause description compared to the previous standard
    A.14.1.2 Securing applications services on public networks – more specific in ISO 27001: 2013 compared to ISO 27001: 2005
    A.14.1.3 Protecting application services transactions – more specific in ISO 27001: 2013 compared to ISO 27001: 2005
    A.14.2.1 Secure development policy – seeks to cover security in the entire development lifecycle, clearer more specific
    A.14.2.6 Secure development environment – this is a new clause
    A.14.2.8 System security testing – this is a new clause
    A.15 Supplier relationships – this is a new domain
    A.15.1.1 Information security policy for supplier relationships – this is a new clause
    A.15.1.2 Addressing security within supplier agreements – this is a new clause
    A.15.1.3 ICT supply chain – this is a new clause
    A.16.1.4 Assessment and decision of information security events – part of incident management this section is clearer
    A.16.1.5 Response to information security incidents – part of incident management this section is more specific to an escalation procedure
    A.17.1 Information security continuity – removes the ambiguity of the previous standard – clearly focuses on protection during continuity
    A.17.2.1 Availability of information processing facilities – part of A.17 Redundancy clause – this is a new requirement

    Summary

    Some of the major changes seem to be ‘alignment with business strategy’, a comprehensive ‘measurable framework’, ‘inclusion of supply chain management’, ‘secure development life cycle’ and a focused incident response process.

    ISO 27001: 2013 is released in September 2013, consider migrating for implementing the best practices. If you are currently certified to iso 27001 – 2005 you have time till September 2015 to migrate.

    Hope this helps!

    Considering migrating to iso 27001 – 2013?

     
  • ISO 27001 2013 Security Performance Dashboard 

    One of the key changes of iso 27001 – 2013 is the introduction of security performance framework in the management requirements. This is necessitated by the following ISO 27001 2013 Clauses

    5.2 – Policy

    Clause 6.2 – Information security objectives and planning to achieve them, and

    Clause 9.2 – Monitoring, measurement, analysis, and evaluation

    Here is how this can be achieved:

    With limited time in your hand, even if you spend 30 minutes in a month, you can review the performance of security using the following key issues.

    Irrespective of whether you are compliant to an international best practice such as ISO 27001 or not, these points will drive teams to be ahead in their security performance.

    1. New asset additions – Addition of new assets pose new challenges for security. Asset can be any new information, new intellectual property, new applications, new technology or physical infrastructure, and even a new service provider. Questioning new asset results in verifying whether adequate controls are in place to protect them.
    2. New risks identified – This follows the new asset additions, but new risks may be a result of other external factors beyond the scope of assets. New risks can be as a result of changes in business strategy, customer requirements, operating environments, legal requirements, hazards and/or financial changes – each of which may have an impact on the risk management. New risks are those that do not have a mitigation plan yet, but information about the risk is relevant for management for risk decisions.
    3. New controls added – this can be a result of recent decision to address a new risk. This can be a new technical, physical, procedural or personnel control. Note that a new control always is perceived negatively as it may be seen as an operations hindrance. So question how successful are these new controls and there implementations.
    4. Attack information – updates from log analysis especially gateway protection devices such as spoofing attacks, unauthorized access attempts to key applications, numbers of servers remaining un-patched despite a ‘critical’ patch release, number of theft attempts captured in CCTV – are some of attack information that helps management keeps track of number of break-in attempts. Consider both attacks within and outside the organization including physical area, industry sector as relevant. Sometimes this is just a trend information as you may not be able to prevent, but will be able to verify whether your Business Continuity Plan can handle such events in they really turn into incidents for you.
    5. Number of new vulnerabilities in the wild relevant to our infrastructure – Availability of independent vulnerability sources such as computer emergency response team (CERT) as well as original equipment manufacturer (OEM) reported vulnerabilities – provides huge information, therefore it is important to pick out vulnerabilities relevant to organizations’ own infrastructure. Having identified the relevant vulnerability and how you are tracking to closure would be of interest to management.
    6. Number of people trained in security – this may be both as part of the joining formalities and technical expertise. This is an indicator of how many are being made of organizations’ policies and gives confidence as to how many are left, if any. Training should also include technical skills as well as restoration skills.
    7. Number of reported vulnerabilities within the organization – this is an important indicator of how people participated in the security process and they are reporting incidents/weaknesses. Note that more people report an incident, more aware is your organization.
    8. Metric performance – if you are compliant to an international standard (such as ISO 27001) you are also required to receive performance of security metrics as part of regular reporting. Unlike previous points, in metrics the management has set a target for performance for a security process. Deviations from the target are a subject of root cause analysis (RCA) and should be investigated as part of the compliance process.

    If you are not getting these reports start asking, after all this a management driven system. Your oversight will drive security compliance to a newer level.

    Hope this helps!

     
  • ISO 27001 – ISO 27002 implementation and certification journey explained 

    ISO 27001/ISO 27002 implementation and certification journey can be divided into the following key phases:

    1. Context Assessment – This phases assess your business, and correlates what is the most important that needs to be protected.
    2. Scope definition – Based on the context, scope helps you define the physical and logical boundary. The decision so taken will impact all the subsequent tasks.
    3. Asset identification – asset is what you are seeking to protect, therefore determining organisation assets is the critical first step. If you don’t identify all the assets, it is highly likely that you will miss the asset under the scope of protection.
    4. Risk assessment – the next and one of the most comprehensive tasks is to evaluate assets and their risks. This would typically involve asset verification, valuation, as well quantifying an assets’ threat, impact, vulnerability, probability analysis resulting in risk valuation for each asset, and one hand, and listing down asset-wise weakness on the other.
    5. Gap analysis against 114 controls – ISO 27001 controls provides a comprehensive (however not exhaustive) controls, and it is important to conduct ‘as-is’ verification of controls that you don’t have. This contributes to the next set of weaknesses.
    6. Vulnerability Assessment/Penetration Testing of your technology infrastructure which includes applications/networks services and associated infrastructure.
    7. Implementation – having identified gaps from the previous three assessments exercise(4,5&6), the journey of implementation should begin. The implementation journey involves decision, direction and documentation of security gaps, and implementation through policy, personnel, procedural and technical controls. The implementation journey involves publishing key organization specific information security policies at the apex level and implementation of each identified control requirement through documented procedures. Documentation also involved writing and publishing ISMS Manuals.
    8. Performance Dashboard or Measurement – You have implemented, alright! What is the proof? This phase involves a measurement framework to be in place that defined a target for each identified control. Management wants return on investment and only by measurement one can show the true benefits. ISO 27001 Clause 6.2 and Clause 9.2 demands performance of ISMS processes.
    9. Internal audit – Final verification of control implementation by an independent team, this phase not only checks control implementation but also lifecycle changes.
    10. Final CB certification – This is where the final certification body arrives and the phase is divided into two major phases – Stage 1 – documentation and stage 2 – implementation audit.

    The whole process can take anywhere between 2-3 months for a smaller organisation (1 location less than 100 people), to 4+  months for a larger organisation. In our experience the delay is not due to size but policy implementation and communication. Also note that this is a management system, so in each phase should be ‘ideally’ signed off by management to track status and progress because for many organisations it is major ‘change-management’ program.

    Coral eSecure has successful implementation methodology which can help organisation of any size and location reach compliance faster, and more comprehensively.

    Interested in knowing what the auditors are looking for, visit our previous blog http://www.www.coralesecure.com/blog/iso-27001-certification-process-explained/

    Hope this helps.

     
  • Scared of ISO 27001 2013 auditor? 

    Scared of the ISO auditor? After reading this blog,  hopefully you will be less scared.

    When any organisation implements ISO 27001 information security management system (ISMS) (or for that matter any ISO) they would engage a certification body (CB) for a formal assessment.  The call for a body should only happen when the organisation has completed one cycle of Plan-Do-Check-Act and is confident that key risks are ‘managed’ and controls identified in the risk assessment are implemented.

    CBs have a panel of lead auditors who would undergo a formal internal certification process before they can take up such roles. Undergoing and passing the lead auditor course is the first step.  Thereafter they have to undergo at least 20 audits (this differs based on accreditation/CB requirement). The ideal auditor is someone who has the necessary knowledge and expertise and more importantly can make a ‘judgment’ about the ISO 27001 compliance. The role is akin a judge of a court who is paid for judgment based on evidence, and nothing else. The auditor makes a judgment based on the principle of ‘not guilty’ unless proven otherwise, where prove equates to evidence of ISO 27001 clause wise implementation.

    There are primary three keywords associated with any certification process when an organization gets certified,  ‘intent, implementation and effectiveness’. In a simplistic view, documentation (such a security policy) is ‘intent’, records (such as change management) are ‘implementation’ and ‘testing’ (e.g. fire evacuation drill) is effectiveness.

    The auditor performs two stages of audit, initial audit stage 1 and initial audit stage 2. Initial audit refers the first year and subsequent year refers to surveillance audits. You get certified for 3 years subject to annual surveillance audits.

    Stage 1 audit also known as documentation audit is aimed at documentation readiness. The simple logic is if you have documentary proof of compliance, you have the necessary ‘intent’.  Stage 1 is especially aimed at management system requirements especially ISO 27001 clause 4 to 10 compliance evidences. A good auditor would spend substantial amount of time in understanding organisation specific enterprise context, key information, assets, asset valuation methodology, risk assessment methodology and risk assessment records. Subsequently they take a physical round of the premise, and then start their audit journey.  They also wish to meet top management to understand the business alignment and benefit of ISMS for the specific organisation.

    Typically stage 1 ends with a formal report and if there are findings that are not adequate he or she may raise ‘minor non conformity’ or ‘major non conformity’. Non conformity is an auditor lingo of stating ‘I am not satisfied with the evidence to a specific clause’ where the clause reference is made for the client to perform further root cause analysis (RCA) or implementation. Once the auditor is satisfied, stage 2 can begin which can be spaced anywhere upwards 7-10 days for most certification bodies.

    Stage 2 audit is aimed at ‘implementation and effectiveness’. Auditors look at evidence of implementation by looking at gap closures from stage 1. In this the focus is assets and controlling processes. They cover applications, network infrastructure, and more importantly security controls that prevent, and/or detect security events. They cover wide variety controls (they have ISO 27001 114 controls to verify on a sampling basis) which covers technical controls, physical security controls, human resources controls and procedural controls. Ideally they should spend more time in technical controls but this can vary depending on an auditors’ own comfort on a subject topic. A lot of time is actually spent on meeting and interacting people, as ‘people’ are the greatest ‘risk’ as most risk assessment will show.

    Typical Dos and Donts

    • Listen to the auditor question, and respond only to the question. Do not exaggerate.
    • If you do not have the answer to a question, simple say ‘i do not know’, rather that than making a false statement. Note that every response the auditor will seek evidence. In such cases you can however state – who would be the right person for the question

    Stage 2 ends with a closing meeting where the auditor would say ‘you are recommended’ a message that everyone is waiting to hear (including consultants like us :-)) that says ‘I did not find any non conformity’ and ‘ I am recommending my CB to issue a certificate’.

    Subsequently every year an auditor arrives and checks for the validity of the compliance policies set on year 1.  The subsequent year assessments are a combination of documentation and implementation and is generally focused on ‘what is new?’. In the subsequent   year they wish to see whether the organisation is improving their ISMS or losing the grip.  They are looking at business lifecycle changes and changes in risk values, latter should be seen decreasing from the first year (assuming everything else remaining the same in that organisation). Theoretically if the auditor is not satisfied, he or she can request the certification body to revoke the certification, which rarely happens in the industry.

    Hope this helps. Let me know your reaction.

    Want to know the difference between iso 27001 2013 and iso 27001 2005?