Communication Procedure

1. Introduction

Customers, users, suppliers and staff judge a service as much by what they are told as by what it does. A planned outage that was announced is an inconvenience; the same outage unannounced is a failure of trust. This procedure makes communication about services a managed activity with named owners, time targets and evidence, rather than something each team improvises during a bad day.

It supports the Service Management Policy and the Service Management System Manual, and it is the place where the communication needs of every other service management process are brought together in one matrix.

2. Purpose

The purpose is to make sure that the right people receive accurate, timely and consistent information about services, service changes, incidents, performance and the service management system itself, and that the Organisation can show who was told what and when.

3. Objectives

• Every interested party that needs to act on or plan around a service event is told before the event where it is planned, and within [the target in the notification table] where it is not.
• Messages about the same event are consistent across channels, because one named person owns the message.
• Staff understand the service management policy, their role in it and how they contribute to the objectives.
• Customer complaints and feedback are received, acknowledged within [1 business day] and answered within [10 business days].
• Evidence of communication is kept so that it can be reviewed at audit and used to improve the plan.

4. Scope

The procedure covers all communication about services that are within the scope of the service management system, in both directions: from the Organisation to customers, users, suppliers, regulators and staff, and from them to the Organisation.

• In scope: incident, major incident, problem and workaround notices; change, release and maintenance notices; service level, availability and capacity reports; continuity and recovery invocations; new, changed and retired services; supplier performance and contract matters; internal service management communication; complaints and satisfaction feedback.
• In scope: all channels used for these messages, including the service portal, email, telephone, chat, status page, meetings and printed notices.
• Out of scope: marketing and public relations material, press statements and investor communication, which are handled by [the Communications function] and only coordinated with this procedure when a service event is public.
• Out of scope: the reporting of information security events to authorities, which follows the Incident Management Procedure; this procedure supplies the customer-facing notice that accompanies it.

5. Terms and Definitions

6. Roles and Responsibilities

7. Principles of Communication

• One owner per message. When several people draft, the message owner approves the final text and the time it is sent.
• Say what is known, what is not known and when the next update will come. Never guess a cause or a fix time in writing.
• Use the audience's own terms: describe the effect on their work, not the internal component that failed.
• Use the channel the audience has agreed to, and a second channel for the highest severity so that a single channel failure does not silence the Organisation.
• Do not put credentials, personal data or details of security weaknesses in notices. Classify and handle content as the Information Classification and Handling Procedure requires.
• Record every notice at the time it is sent, with the time, channel, audience and approver.

8. Communication Matrix

The matrix below is the controlled list of what is communicated. The process manager reviews it every [6 months] and whenever a new service, customer or channel is added. Where a row conflicts with a customer agreement, the agreement prevails and the row is amended.

9. Internal Communication

9.1 Communication to staff about the service management system

The Management representative makes sure that staff and contractors working on services know the Service Management Policy, the service management objectives that concern them, how their work contributes to the effectiveness of the system, and what follows from not conforming. This is done at induction, by a briefing within [30 days] of each approved change to the policy or objectives, and by an annual reminder.

• Process owners brief their teams on changes to procedures before the change takes effect.
• Attendance or acknowledgement is recorded in the training and awareness record.
• Staff can ask questions through [the service management mailbox], answered within [3 business days].

9.2 Operational communication between teams

Shift handover, resolver group escalation and change calendar publication are internal communications. The service desk publishes the change calendar to all support teams [weekly], and the Incident manager opens a conference bridge for every severity 1 incident within [10 minutes] of classification. The bridge keeps a running log in the ticket.

9.3 Escalation to management

Escalation follows the escalation matrix in the Service Operating Model. The message owner tells Top management of any severity 1 incident within [30 minutes], of any expected breach of a contractual service level, and of any event likely to appear in public media.

10. External Communication

10.1 Customers and users

Customer representatives are agreed with each customer through the Business Relationship Management Procedure, with the preferred channel, a second channel, working hours and an escalation contact. The service desk checks these details at each service review and at least [every 6 months]. Notices go to the customer representative and, where the agreement says so, to named users.

Users are told how to report faults and ask for services in the service catalogue and on the portal. The Service desk confirms receipt of each report as the Service Incident Management Procedure and the Service Level Management Procedure require.

10.2 Suppliers

The Supplier manager records each supplier's operations contact, escalation path and notification duties. Suppliers must tell the Organisation of outages and security events within the period set in the contract, normally [2 hours] for events that affect delivery of a service. The Supplier manager passes the information to the Incident manager, who decides on the customer notice.

10.3 Authorities and regulators

Where a service event is also a reportable cyber incident, the Incident Management Procedure governs the report to the authority, for example the CERT-In Directions of 28 April 2022, which require cyber incidents to be reported within 6 hours of noticing [confirm the current requirement]. The Incident manager tells the Message owner when a report is made, and the customer notice is aligned with it. Where personal data is affected, the Data Protection and Privacy Procedure decides what is said to the Data Protection Board and to affected individuals under the Digital Personal Data Protection Act, 2023 and its Rules [confirm the current requirement]. Only people named in the Incident Management Procedure speak to authorities.

10.4 Public statements

Anything said in public media or on public social channels about a service failure is approved by [the Chief Executive Officer or delegate] and prepared with [the Communications function]. Staff who are asked by media or customers outside the agreed channels refer the request to the Service Delivery Manager.

11. Incident Notifications

Notices follow the severity classification in the Service Operating Model and the Service Incident Management Procedure. The timings below are the default for customers without a specific agreement.

11.1 Steps for a major incident notice

1. ClassifyThe Incident manager confirms severity 1 and takes ownership of the message. Time target: [10 minutes] from first report.
2. Holding statementThe Incident manager approves the holding statement from Annexure A and the Service desk publishes it on the status page and emails customer representatives. Target: [15 minutes].
3. Second channelThe Service desk telephones customers who have asked for voice contact and posts the same text on the second channel. Target: [30 minutes].
4. UpdatesAt each interval the Incident manager approves an update stating status, effect, workaround and the time of the next update, even when nothing has changed. The Service desk publishes it within [10 minutes] of approval.
5. RestorationOn confirmed restoration the Incident manager approves the closure notice and the Service desk publishes it. Target: [30 minutes].
6. ReportThe Service owner issues the post-incident report using Annexure B, covering timeline, cause as far as known, effect, actions and owners. Target: [5 business days].
7. RecordThe Service desk stores each notice in the incident record and updates the communication log.

12. Change and Maintenance Notifications

The Change authority sets the notice period when it approves a change, using the table below. The notice is issued by the Service desk from the template in Annexure C and is attached to the change record. A change with customer impact must not start until the record shows that the notice was sent and the lead time has been met, unless the change is an emergency change.

After the work the Service desk issues a completion notice within [30 minutes] of the Release manager confirming the outcome. If the change is backed out, the notice says so, says what happens next and gives a new date only when the Change authority has approved one.

13. Complaints and Feedback

Any member of staff who receives a complaint passes it to the Service desk on the day. The Service desk logs it, acknowledges it within [1 business day], and sends it to the Service owner, who investigates and gives the complainant a written answer within [10 business days]. Complaints that are not resolved are escalated to the Service Delivery Manager and, if still open after [30 days], reported at management review.

Satisfaction is measured through the survey described in the Service Reporting and Continual Improvement Procedure. Comments are read by the Process manager and entered in the improvement register when they show a pattern.

14. Communication Process

14.1 Inputs and outputs

14.2 Process steps

1. IdentifyThe owner of the triggering process (incident, change, release, supplier or reporting) identifies that a message is due by checking the matrix. Target: at the time of the event.
2. SelectThe message owner picks the matching row, the template and the audience list from the contact register. Target: [5 minutes].
3. DraftThe Service desk or the process manager drafts the message in plain words from the template, with no personal data beyond what the audience needs. Target: [10 minutes] for incidents.
4. ApproveThe message owner approves. Messages with customer impact beyond the Service owner's delegation are approved by the Service Delivery Manager. Target: [10 minutes].
5. SendThe Service desk sends on the agreed channels, and a second person checks that the message is visible on each channel. Target: within the time in the matrix.
6. RecordThe sender enters the notice, time, channel and approver in the communication log and attaches it to the ticket or change record.
7. Follow upThe message owner checks replies, answers questions and sets the next update time. Target: [1 hour] for severity 1 and 2, [1 business day] otherwise.
8. ReviewThe process manager samples the log monthly against the matrix and reports misses to the process owner.

14.3 Process flow

1. An event occurs or is planned: incident, change, release, outage, report, complaint or policy change.
2. The owner checks the communication matrix for the matching message type.
3. If no row matches, the process manager adds one within [5 business days] and the owner sends a message using the closest template in the meantime.
4. The message owner drafts and approves the message from the template.
5. The Service desk sends the message on the primary channel and, for severity 1 or critical changes, on the second channel.
6. The sender records the notice in the log and attaches it to the ticket.
7. Replies and questions are handled by the message owner; complaints go to the complaints step.
8. At closure of the event the closure message is sent and the record is completed.
9. Monthly, the process manager checks timeliness and content against the matrix and feeds results to the improvement register.

15. Interfaces with Other Processes

16. Key Performance Indicators

17. Records and Evidence

Annexure A: Incident notification template

Annexure B: Post-incident report template

Annexure C: Change and maintenance notice template

Annexure D: Communication log

Annexure E: Contact register

Annexure F: Document history

18. Exception

Exceptions to this document are allowed only where compliance is not practicable and the risk has been assessed. A request must state what is to be excepted, why, the risk it creates, the compensating controls, and an end date no later than [6 months]. It is approved in writing by the document owner and the risk owner, recorded in the exceptions register, and reviewed at the end date. An exception does not change the document.

19. Enforcement

Compliance is monitored through internal audits, management review and routine checks by the document owner. Non-compliance is reported through the incident or non-conformity process and handled under the organisation's disciplinary procedure, and under the terms of any contract for people who are not employees. Serious or repeated non-compliance may lead to loss of access and, where the law is broken, to referral to the authorities.

20. Review

This document is reviewed at least every [12 months], and when there is a significant change to the organisation, its systems, its risks or the law, or after an incident that shows it was not effective. Each review is recorded in the revision history.

ISO/IEC 20000-1:2018 references

Related documents

• Service Incident Management Procedure
• Change Management Procedure
• Business Relationship Management Procedure
• Service Level Management Procedure
• Release and Deployment Management Procedure
• Availability and Service Continuity Management Procedure
• Incident Management Procedure
• Supplier Management Procedure