{"id":79566,"date":"2026-10-28T07:41:38","date_gmt":"2026-10-28T07:41:38","guid":{"rendered":"https:\/\/www.devopsschool.com\/blog\/?p=79566"},"modified":"2026-10-28T07:41:40","modified_gmt":"2026-10-28T07:41:40","slug":"it-service-management-and-governance-how-itil-cobit-iso-iec-20000-1-fitsm-verism-iso-22301-and-iso-31000-work-together","status":"publish","type":"post","link":"https:\/\/www.devopsschool.com\/blog\/it-service-management-and-governance-how-itil-cobit-iso-iec-20000-1-fitsm-verism-iso-22301-and-iso-31000-work-together\/","title":{"rendered":"IT Service Management and Governance: How ITIL, COBIT, ISO\/IEC 20000-1, FitSM, VeriSM, ISO 22301, and ISO 31000 Work Together"},"content":{"rendered":"\n

Modern services need more than a single framework. They need useful customer outcomes, repeatable operations, executive decisions, risk controls, and proven continuity. Seven complementary approaches address these requirements from different angles.<\/p>\n\n\n\n

Which framework answers which question?<\/h2>\n\n\n\n
Framework<\/th>Main question<\/th>Strength<\/th>Formal assessment distinction<\/th><\/tr><\/thead>
ITIL<\/td>How should we design, deliver, support, and continually improve digital products and services?<\/td>Value-oriented service-management practices<\/td>PeopleCert offers defined practice and maturity assessment approaches; check the version and scope<\/td><\/tr>
COBIT<\/td>How should enterprise leaders govern information and technology decisions?<\/td>Governance objectives, design factors, and performance management<\/td>COBIT supports process capability and governance-system assessment under specified methods<\/td><\/tr>
ISO\/IEC 20000-1<\/td>How can we run an effective, auditable service management system?<\/td>Certifiable SMS requirements<\/td>Certification tests requirements conformance within scope, not a universal 1\u20135 maturity rating<\/td><\/tr>
FitSM<\/td>How do we establish practical ITSM with limited resources or multiple providers?<\/td>Free, lightweight requirements, roles, and processes<\/td>FitSM-6 has a defined capability\/maturity assessment approach<\/td><\/tr>
VeriSM<\/td>How can the entire enterprise deliver flexible, outcome-driven services?<\/td>Consumer-centric model and Management Mesh<\/td>No single mandatory universal maturity-scale interpretation<\/td><\/tr>
ISO 22301<\/td>How do we sustain and recover prioritized activities during disruption?<\/td>Certifiable business continuity management system<\/td>Conformity and effectiveness assessment; no mandated maturity ladder<\/td><\/tr>
ISO 31000<\/td>How do we make better decisions under uncertainty?<\/td>Principles, framework, and risk process<\/td>Guidance standard; not an organizational certification standard<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

A combined operating model<\/h2>\n\n\n
Enterprise purpose and stakeholder expectations\n                     |\n       COBIT: governance and direction\n                     |\n       ISO 31000: risk decisions\n                     |\n     VeriSM: consumer value and service design\n                     |\n ITIL \/ FitSM: practical service management\n                     |\n  ISO\/IEC 20000-1: SMS requirements and assurance\n                     |\n     ISO 22301: continuity and resilience\n                     |\n           Evidence and feedback\n                     |\n          Continual improvement\n<\/code><\/span><\/pre>\n\n\n
This is an illustrative integration<\/strong>, not an official hierarchy or a requirement to implement the frameworks in this exact order. A smaller organization might begin with FitSM and adopt COBIT objectives only where governance needs justify them. A regulated provider may build ISO\/IEC 20000-1 and ISO 22301 management systems with ITIL practices supplying implementation guidance. Different teams may organize this integration in different ways.<\/p>\n\n\n\n
Capstone case: make an online payment service resilient<\/h2>\n\n\n\n
A retailer runs its checkout service through a web application, managed database, cloud infrastructure, and third-party payment provider. Frequent outages affect revenue, changes are poorly coordinated, supplier ownership is unclear, and executives do not know whether continuity promises can be met.<\/p>\n\n\n\n
VeriSM \u2014 Define the consumer outcome:<\/strong> Customers should complete purchases securely with predictable service behavior. Map the end-to-end experience, including user-facing errors, refunds, support, and incident communication. Select resources, operating practices, and technology through a Management Mesh.<\/p>\n\n\n\n
COBIT \u2014 Establish decision rights:<\/strong> Leadership defines business outcomes, investment limits, risk appetite, supplier oversight, and the authority to approve consequential changes. Select governance and management objectives appropriate to these risks rather than assessing every objective at once.<\/p>\n\n\n\n
ISO 31000 \u2014 Understand uncertainty:<\/strong> Identify risks such as supplier outage, deployment failure, authentication issues, fraud-control errors, and inadequate recovery capability. Evaluate each against enterprise risk criteria and assign accountable treatment owners.<\/p>\n\n\n\n
ITIL \u2014 Operate and improve:<\/strong> Define the service, incident response, restoration, change enablement, problem management, monitoring, and continual improvement. Measure business effects as well as technical stability.<\/p>\n\n\n\n
FitSM \u2014 Keep the implementation practical:<\/strong> Use lightweight service records, roles, supplier contacts, incident logs, change histories, reporting, and a manageable improvement backlog. FitSM is especially useful when organizations must coordinate multiple providers without a single reporting hierarchy.<\/p>\n\n\n\n
ISO\/IEC 20000-1 \u2014 Establish management-system assurance:<\/strong> Define the SMS scope, requirements, documented service commitments, accountable management, supplier interfaces, operational controls, audit, management review, and corrective action.<\/p>\n\n\n\n
ISO 22301 \u2014 Validate continuity:<\/strong> Perform a BIA, establish approved recovery objectives, create viable recovery arrangements, test technical and business restoration, and correct gaps discovered by exercises.<\/p>\n\n\n\n
What an integrated evidence pack might contain<\/h2>\n\n\n\n
Artifact<\/th>Primary use<\/th>Other frameworks that benefit<\/th><\/tr><\/thead>
Service catalog and ownership map<\/td>Service scope and accountability<\/td>ITIL, FitSM, ISO\/IEC 20000-1, VeriSM<\/td><\/tr>
Business objective and decision-rights record<\/td>Governance direction<\/td>COBIT, ISO 31000<\/td><\/tr>
Risk register and treatment decisions<\/td>Informed risk ownership<\/td>ISO 31000, COBIT, ISO 22301<\/td><\/tr>
Incident, problem, and change records<\/td>Controlled service operations<\/td>ITIL, FitSM, ISO\/IEC 20000-1<\/td><\/tr>
BIA, continuity strategies, exercise results<\/td>Recovery readiness<\/td>ISO 22301, ISO\/IEC 20000-1<\/td><\/tr>
Supplier agreements and review reports<\/td>Management of dependencies<\/td>FitSM, ITIL, COBIT, ISO\/IEC 20000-1<\/td><\/tr>
Audit, management review, corrective-action records<\/td>Evidence of continual improvement<\/td>ISO\/IEC 20000-1, ISO 22301<\/td><\/tr>
Consumer outcome dashboard<\/td>Demonstrated customer value<\/td>VeriSM, ITIL, COBIT<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
Use one source of truth for shared evidence where practical. A single controlled incident record may support operational review, management reporting, and audit sampling. Avoid duplicating logs just because two frameworks use slightly different terminology.<\/p>\n\n\n\n
A practical 90-day improvement roadmap<\/h2>\n\n\n\n
Phase<\/th>Main work<\/th>Tangible output<\/th><\/tr><\/thead>
Days 1\u201330<\/td>Define critical services, desired outcomes, owners, risks, and current performance<\/td>Service catalog, baseline metrics, top-risk list<\/td><\/tr>
Days 31\u201360<\/td>Establish incident\/change handling, supplier interfaces, governance decisions, and continuity priorities<\/td>Working workflows, decision rules, preliminary BIA<\/td><\/tr>
Days 61\u201390<\/td>Conduct recovery exercises, audit a sample of records, review executive outcomes, and resolve highest-risk gaps<\/td>Exercise evidence, audit findings, verified improvement plan<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
The time ranges are illustrative. Formal management-system certification or large-enterprise transformation may require substantially greater preparation.<\/p>\n\n\n\n
Avoid the four most consequential assessment mistakes<\/h2>\n\n\n\n
    \n
  1. Certification is not process maturity.<\/strong>\u00a0Conformity to an ISO management-system standard should not be converted into an invented numeric capability score.<\/li>\n\n\n\n
  2. Personal qualifications are not organizational certificates.<\/strong>\u00a0A certified practitioner cannot, by themselves, make an enterprise compliant or mature.<\/li>\n\n\n\n
  3. Rating schemes are not interchangeable.<\/strong>\u00a0An ITIL maturity level, COBIT process capability level, and FitSM-6 assessment result have different criteria and scopes.<\/li>\n\n\n\n
  4. Evidence of an activity is not evidence of an outcome.<\/strong>\u00a0A completed backup job, closed incident, or approved change must still be assessed for actual service effectiveness.<\/li>\n<\/ol>\n\n\n\n
    The seven standalone tutorials<\/h2>\n\n\n\n
      \n
    1. ITIL \u2014 digital products and service management<\/a><\/li>\n\n\n\n
    2. COBIT \u2014 enterprise technology governance<\/a><\/li>\n\n\n\n
    3. ISO\/IEC 20000-1 \u2014 service management system<\/a><\/li>\n\n\n\n
    4. FitSM \u2014 lightweight IT service management<\/a><\/li>\n\n\n\n
    5. VeriSM \u2014 enterprise-wide service management<\/a><\/li>\n\n\n\n
    6. ISO 22301 \u2014 business continuity<\/a><\/li>\n\n\n\n
    7. ISO 31000 \u2014 enterprise risk management<\/a><\/li>\n<\/ol>\n\n\n\n
      Start with the framework that solves your most pressing problem, then add the others where they provide clear business value. Service management succeeds when the organization can explain what customers need, who is accountable, how risks are handled, and whether measured outcomes are actually improving.<\/p>\n\n\n\n
      \n\n\n\n
      ITIL Explained: A Practical Guide to Service Management, Digital Products, Incidents, Changes, and Continual Improvement<\/h1>\n\n\n\n
      An online payment stops working during a busy shopping period. Customers cannot complete orders, engineers are investigating several alerts, support agents are receiving complaints, and managers want an accurate recovery estimate. The technical fix matters, but the organization also needs coordinated communication, clear accountability, prioritization, and a way to prevent the next outage.<\/p>\n\n\n\n
      This is the kind of problem ITIL helps organizations solve. ITIL is a body of best-practice guidance for managing digital products and services so they create value for the people and organizations that depend on them. It is not a software package, a ticketing tool, or a law requiring every organization to operate in exactly the same way.<\/p>\n\n\n\n
      1. The mental model: services, value, and outcomes<\/h2>\n\n\n\n
      A service<\/strong> enables a customer to achieve an outcome without having to manage all the underlying costs and risks personally. A payroll service, for example, lets HR pay employees without running the payroll infrastructure itself. The service provider still needs infrastructure, processes, suppliers, people, knowledge, and governance.<\/p>\n\n\n\n
      Several terms are easily confused:<\/p>\n\n\n\n
      Term<\/th>Meaning<\/th>Payment-platform example<\/th><\/tr><\/thead>
      Product<\/td>Configuration of resources designed to offer value<\/td>Payment-processing application and its supporting platform<\/td><\/tr>
      Service<\/td>Means of enabling customer outcomes<\/td>Reliable payment acceptance for merchants<\/td><\/tr>
      Outcome<\/td>Result a customer wants<\/td>An order is successfully paid<\/td><\/tr>
      Output<\/td>A delivered activity or artifact<\/td>A processed API request or settlement report<\/td><\/tr>
      Utility<\/td>Fitness for purpose: does it do the needed job?<\/td>Supports the required card and payment methods<\/td><\/tr>
      Warranty<\/td>Fitness for use: can it be relied on?<\/td>Suitable availability, capacity, security, and continuity<\/td><\/tr>
      Incident<\/td>Unplanned interruption or degradation of a service<\/td>Checkout requests begin failing<\/td><\/tr>
      Problem<\/td>Cause, or potential cause, of one or more incidents<\/td>Faulty connection-pool configuration<\/td><\/tr>
      Change<\/td>Addition, modification, or removal affecting services<\/td>Updating connection-pool settings<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
      Value is co-created.<\/strong> Providers supply capabilities, but customers and users participate by providing requirements, using services, and giving feedback. A service can have perfect infrastructure availability yet be unsuccessful if it does not meet the customer\u2019s needs.<\/p>\n\n\n\n
      2. ITIL 4 and ITIL (Version 5): what changed?<\/h2>\n\n\n\n
      ITIL 4 established a value-oriented view of service management through the service value system (SVS)<\/strong>, guiding principles, governance, management practices, continual improvement, and service value chain. Its four dimensions encourage balanced decisions across people, information and technology, partners and suppliers, and value streams and processes.<\/p>\n\n\n\n
      ITIL (Version 5)<\/strong> builds on those concepts and makes digital products and services<\/strong> more explicitly connected. Its product and service lifecycle model describes eight activities: Discover, Design, Acquire, Build, Transition, Operate, Deliver, and Support<\/strong>. These activities interact and repeat; they should not be imposed as a rigid waterfall process. The updated guidance also places greater emphasis on AI-enabled work, complexity, product management, experience, and governance.<\/p>\n\n\n\n
      A helpful way to picture the relationship is:<\/p>\n\n\n
      Customer need and business objective\n              |\n      Discover and design\n              |\n      Acquire and build\n              |\n           Transition\n              |\n    Operate, deliver, support\n              |\n Feedback, measurement, improvement\n              +----> informs every stage\n<\/code><\/span><\/pre>\n\n\n
      ITIL (Version 5) is being released in phases. ITIL 4 training and certifications may still be relevant during the transition. Use the edition and official syllabus that match the certification or organizational assessment you actually intend to pursue. Do not assume that a maturity assessment built around an ITIL 4 service value system automatically has identical rules under every new edition.<\/p>\n\n\n\n
      3. Seven guiding principles translated into behavior<\/h2>\n\n\n\n
      ITIL\u2019s guiding principles are practical decision tests, not slogans:<\/p>\n\n\n\n
        \n
      1. Focus on value:<\/strong>\u00a0Ask whether an activity improves an outcome customers care about. A faster escalation process may matter more than a prettier dashboard.<\/li>\n\n\n\n
      2. Start where you are:<\/strong>\u00a0Examine existing ticket records, monitoring, on-call schedules, and service ownership before buying a replacement system.<\/li>\n\n\n\n
      3. Progress iteratively with feedback:<\/strong>\u00a0Pilot incident categories with one service before reorganizing every department.<\/li>\n\n\n\n
      4. Collaborate and promote visibility:<\/strong>\u00a0Give support, engineering, security, and business stakeholders one common incident timeline.<\/li>\n\n\n\n
      5. Think and work holistically:<\/strong>\u00a0Account for technology, people, suppliers, contracts, customer experience, and compliance together.<\/li>\n\n\n\n
      6. Keep it simple and practical:<\/strong>\u00a0Remove approval stages that add delay without controlling meaningful risk.<\/li>\n\n\n\n
      7. Optimize and automate:<\/strong>\u00a0Stabilize a process before automating it; automate repetitive classification and routing, not judgment that requires accountability.<\/li>\n<\/ol>\n\n\n\n
        4. The practices you should implement first<\/h2>\n\n\n\n
        ITIL has a broad portfolio of management practices. Most teams should begin with the practices that solve their actual problems rather than trying to implement the entire catalog at once.<\/p>\n\n\n\n
        Practice<\/th>Core question<\/th>Minimum useful artifact<\/th><\/tr><\/thead>
        Service desk<\/td>Where does a user go for help?<\/td>Accessible support channel and ownership map<\/td><\/tr>
        Incident management<\/td>How do we restore service quickly?<\/td>Incident record, severity rules, escalation path<\/td><\/tr>
        Service request management<\/td>How do we fulfill routine requests?<\/td>Request catalog and fulfillment rules<\/td><\/tr>
        Problem management<\/td>How do we reduce recurring incidents?<\/td>Problem record, root-cause findings, known-error\/workaround notes<\/td><\/tr>
        Change enablement<\/td>How do we make changes with acceptable risk?<\/td>Change record, risk assessment, approval model, rollback plan<\/td><\/tr>
        Service level management<\/td>What outcomes are agreed and measured?<\/td>Service objectives and regular review notes<\/td><\/tr>
        Monitoring and event management<\/td>How do we detect meaningful conditions?<\/td>Actionable alerts and service-health views<\/td><\/tr>
        Continual improvement<\/td>How do we make performance measurably better?<\/td>Improvement backlog, owners, baselines, results<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
        Incident, problem, and change are different workflows.<\/strong> An incident aims to restore service; a problem investigation finds or manages underlying causes; change enablement controls the risk of introducing a modification. One outage may create records in all three practices, but they have different objectives and may progress at different speeds.<\/p>\n\n\n\n
        5. Build an incident-management workflow<\/h2>\n\n\n\n
        Consider a checkout API returning errors for 30% of payment attempts.<\/p>\n\n\n\n
        Step 1 \u2014 Detect and log.<\/strong> Monitoring reports an increased error rate. The on-call responder creates an incident containing the affected service, start time, symptoms, customer impact, and initial hypothesis.<\/p>\n\n\n\n
        Step 2 \u2014 Classify and prioritize.<\/strong> Use impact and urgency. A critical checkout failure affecting many paying customers could be designated P1 under the organization’s own severity policy. P1, P2, and similar labels are local definitions, not universal ITIL time limits.<\/p>\n\n\n\n
        Step 3 \u2014 Assign roles.<\/strong> Appoint an incident commander for coordination, a technical lead for restoration, and a communications owner for updates. In a smaller organization one person may perform multiple roles, provided accountability remains clear.<\/p>\n\n\n\n
        Step 4 \u2014 Stabilize and restore.<\/strong> Engineers investigate recent releases, databases, queues, dependency errors, and capacity. A rollback or failover may restore service before the deeper cause is known.<\/p>\n\n\n\n
        Step 5 \u2014 Communicate.<\/strong> Publish confirmed impact and the next update time; avoid invented recovery estimates. Internal and external audiences may require different messages.<\/p>\n\n\n\n
        Step 6 \u2014 Validate and close.<\/strong> Confirm user journeys work, monitor error rates, document actual restoration time, and obtain appropriate service-owner acknowledgment.<\/p>\n\n\n\n
        Step 7 \u2014 Learn.<\/strong> Open a problem investigation if the event is significant or recurrent. Record contributing factors, follow-up changes, and action owners.<\/p>\n\n\n\n
        An incident record might look like this:<\/p>\n\n\n\n
        Field<\/th>Illustrative entry<\/th><\/tr><\/thead>
        Incident ID<\/td>INC-1042<\/td><\/tr>
        Service<\/td>Online checkout<\/td><\/tr>
        Detected<\/td>09:10<\/td><\/tr>
        Business impact<\/td>Some customers unable to complete payments<\/td><\/tr>
        Severity<\/td>P1 under local policy<\/td><\/tr>
        Workaround<\/td>Revert the latest deployment<\/td><\/tr>
        Service restored<\/td>09:52<\/td><\/tr>
        Follow-up<\/td>Test connection-pool limits under peak load<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
        Here the time to restore<\/strong> is 42 minutes. That does not mean the root cause was resolved in 42 minutes.<\/p>\n\n\n\n
        6. Make change enablement compatible with DevOps<\/h2>\n\n\n\n
        Change enablement should manage risk rather than require the same meeting for every deployment. Distinguish routine, well-understood changes from unusual changes needing more scrutiny. For a low-risk application release, automated test evidence, peer review, feature flags, and a reliable rollback may provide stronger control than a manual change-advisory-board meeting.<\/p>\n\n\n\n
        Use a small change record covering the service, expected impact, deployment owner, risk, verification plan, customer communication if required, and rollback trigger. An emergency change still needs clear authorization and post-implementation review, but its path may be accelerated.<\/p>\n\n\n\n
        Example decision rule:<\/strong> Automatically approve a well-tested, repeatable change when pre-agreed conditions are met; require an accountable human review if it changes payment authentication, modifies customer data, or crosses a defined business-risk threshold. These are illustrative company policies, not universal ITIL mandates.<\/p>\n\n\n\n
        7. Measure what matters<\/h2>\n\n\n\n
        Useful metrics connect service behavior to customer outcomes:<\/p>\n\n\n\n
        Metric<\/th>Calculation or interpretation<\/th>Warning<\/th><\/tr><\/thead>
        Service availability<\/td>Successful service time \/ agreed service time<\/td>Define measurement boundaries and exclusions<\/td><\/tr>
        Mean time to restore (MTTR)<\/td>Total restoration durations \/ incidents<\/td>State whether using mean or median and the exact event set<\/td><\/tr>
        Incident recurrence rate<\/td>Repeated incidents \/ relevant incidents<\/td>Requires consistent classification<\/td><\/tr>
        Change failure rate<\/td>Changes causing service degradation \/ relevant changes<\/td>Define failures and measurement window<\/td><\/tr>
        Request fulfillment time<\/td>Elapsed time from accepted request to completion<\/td>Segment by request type<\/td><\/tr>
        Customer satisfaction<\/td>Feedback associated with completed experiences<\/td>Beware response and sample bias<\/td><\/tr>
        Improvement completion<\/td>Actions completed with verified benefit \/ planned actions<\/td>Closing tickets alone does not prove improvement<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
        Avoid optimizing ticket-closure counts while users still suffer. Pair operational indicators with customer measures, such as checkout success, employee productivity, or time to obtain access.<\/p>\n\n\n\n
        8. ITIL maturity and practice capability<\/h2>\n\n\n\n
        ITIL is not synonymous with a universal maturity number. PeopleCert offers a defined ITIL Maturity Model<\/strong> that can assess practice capability and, under relevant assessment scopes, organizational service-management maturity. Its published model includes five levels, commonly presented from Initial<\/strong> through Managed, Defined, Quantitative, and Optimizing<\/strong>. The meaning of each level and the scope of an assessment depend on the official method being applied.<\/p>\n\n\n\n
        An internal gap review is useful but should never be presented as an official ITIL maturity assessment. Document the chosen assessment method, practices assessed, evidence, evaluator, date, findings, and follow-up actions.<\/p>\n\n\n\n
        9. Hands-on lab: create a service-management starter kit<\/h2>\n\n\n\n
        Scenario:<\/strong> A 50-person SaaS company has an operations team, a support inbox, basic application monitoring, and frequent deployment-related outages.<\/p>\n\n\n\n
        Exercise A \u2014 Service definition.<\/strong> Create a one-page record for the production API containing a business owner, technical owner, customer groups, critical dependencies, support hours, major failure scenarios, and three measurable objectives.<\/p>\n\n\n\n
        Exercise B \u2014 Incident simulation.<\/strong> Announce that API error rates exceed the team’s trigger threshold. Record detection time, incident commander, user impact, one communications update, recovery action, and confirmation of restoration.<\/p>\n\n\n\n
        Exercise C \u2014 Change guardrail.<\/strong> Define one pre-authorized low-risk change type and one high-risk change type. Specify the tests, approval, monitoring, and rollback evidence for each.<\/p>\n\n\n\n
        Exercise D \u2014 Improvement review.<\/strong> Select a recurring failure and write a single measurable improvement hypothesis, such as: \u201cDeployment-related incidents will decline after rollout health checks and automatic rollback are introduced.\u201d Capture baseline and follow-up results.<\/p>\n\n\n\n
        A successful lab produces four tangible artifacts: a service record, completed incident timeline, two change-control examples, and an improvement item with an owner and measurement plan.<\/p>\n\n\n\n
        10. A practical adoption sequence<\/h2>\n\n\n\n
        First month:<\/strong> Identify critical services and owners; collect baseline ticket and monitoring data; agree on incident severity, escalation, and communication conventions.<\/p>\n\n\n\n
        Second month:<\/strong> Introduce change-risk rules, service requests, knowledge articles, post-incident reviews, and service-level reporting for selected services.<\/p>\n\n\n\n
        Third month:<\/strong> Connect problem management with the improvement backlog, review supplier dependencies, measure user outcomes, and reassess which practices need investment.<\/p>\n\n\n\n
        This timeline is illustrative. A complex regulated enterprise may need a longer governance and assurance effort.<\/p>\n\n\n\n
        Common mistakes<\/h2>\n\n\n\n