Communications and Operations Security Policy

1. Purpose

This policy sets the rules for running the Organisation's information processing facilities and communications safely: how operating procedures are written and kept, how changes are controlled, how data is backed up and restored, how networks and media are protected, how information is exchanged, how activity is logged, and how malware and capacity problems are prevented.

It aims to make sure that systems operate correctly and securely, that no single person or change can cause serious harm unnoticed, and that information in transit and at rest keeps its confidentiality, integrity and availability throughout day-to-day operation.

2. Scope

• In scope: servers, endpoints, network and security devices, storage, databases, applications, cloud services used by the Organisation, communication services (email, messaging, voice and video, file transfer), removable media, backups, logs, and the people and suppliers who operate them.
• In scope: production, pre-production, test and development environments, and customer-facing platforms hosted by or for the Organisation.
• Out of scope: physical security of buildings and rooms, covered by the Physical and Environmental Controls Policy; rules on user behaviour, covered by the Acceptable Usage Policy; and software development controls, covered by the Systems Acquisition, Development and Maintenance Policy.

The policy applies to employees, contractors and suppliers who design, operate, administer, change or monitor these facilities.

3. Terms and Definitions

4. Roles and Responsibilities

5. Communications and Operations Policy Statements

5.1 Documented Operating Procedures

• Every recurring operational activity on production systems must have a written operating procedure that has an owner, a version, an approval date and a review date. The activities include start-up and shutdown, restart and recovery, back-up, job scheduling, patching, monitoring, handling of errors and exceptions, output handling, support contacts and escalation.
• Procedures must say who may perform the task, the steps, the checks that show success, what to do on failure, and who to call. They must not contain passwords or keys.
• Procedures are stored in the document management system, or an equivalent controlled location, with read access to all who need it and write access only to owners. Printed copies are uncontrolled.
• Procedures are reviewed at least [every 12 months] and after any change that affects them. Operators must not rely on memory or unwritten practice for a task that has a procedure.
• Where a procedure cannot be followed, the operator stops, records the reason and gets approval from the system owner before continuing in another way.
• New operators are trained on the procedures they use before being allowed to run them alone; training is recorded.

5.2 Operational Change Management

All changes to production systems are made through the process in the Change Management Policy and Procedure. The minimum rules here apply to every change, including those made by suppliers.

• Every change has a record that states the reason, the systems affected, the risk, the security impact, the test results, the implementation plan, the roll-back plan, the time window and the people involved.
• No change is made until it is approved by the authority shown in the table below. The person who approves a change must not be the person who implements it.
• Changes are tested in a non-production environment that reflects production, and the test results are attached to the record before approval for Normal and Major changes.
• Roll-back steps are tested or at least rehearsed on paper, and a decision point is set at which the change will be undone.
• Affected users and customers are told before and after changes that may affect service. A post-change review confirms that the change worked and that no unexpected effects occurred, within [2 working days] for Normal changes and [5 working days] for Major ones.
• Emergency changes may be approved verbally by the on-call manager, but must be recorded and reviewed by the change manager within [2 working days] of implementation.

5.3 Segregation of Duties

Where it is practical, tasks must be split so that no one person can complete a sensitive process alone. Where it is not (for example in a small team), compensating controls must be applied: closer monitoring, activity logs reviewed by someone independent, and approval by a manager.

• Each system owner records the conflicting roles in the access matrix and reviews it [every 6 months].
• Where a conflict has to be accepted, the exception is approved by the Head of IT Security and logged, and the privileged activity concerned is reviewed [weekly].
• Segregation applies to suppliers and contractors with the same strictness as to employees.

5.4 Separation of Development, Test and Production

• Development, test and production environments must be logically or physically separated, with separate accounts, credentials and network segments. Staff move software between them only through the release process.
• Development and test staff do not have standing access to production. Access for support is time-limited, approved and recorded in the ticket.
• Compilers, editors and development tools are not installed on production systems.
• Test and production systems display different identifiers, such as a banner or colour, so that mistakes are less likely.
• Production data is not copied into test environments unless it is masked or protected as the Systems Acquisition, Development and Maintenance Policy requires.

5.5 Information Backup and Recovery

Backups protect against loss through failure, error, attack and disaster. The Backup and Restoration Policy and the Backup Management and Retention Procedure carry the full rules; the requirements below apply to every system.

• Backups are encrypted in transit and at rest with keys held under the Key Management Process, and access to backup systems is restricted to named administrators using multi-factor authentication.
• A copy of critical backups is kept offline or immutable so that an attacker or ransomware with administrative rights cannot delete or encrypt it.
• Backup jobs are monitored. Failed or incomplete jobs are corrected and re-run within [one working day], and repeated failures are raised as problems.
• Backup media that leaves the premises is carried and stored as set out in the Physical and Environmental Controls Policy, and is recorded in the media register.
• Retention follows the schedule in the Backup Management and Retention Procedure. Where personal data is held in backups, the retention must be consistent with the Data Protection and Privacy Policy.
• Cloud services must provide backup that meets the same objectives, or the Organisation must make its own copies. The contract is checked for this before purchase.

5.6 Recovery Rules

• Each critical system has a documented recovery procedure that can be followed by someone other than its normal administrator, with the order of restoration, dependencies, contacts, and the evidence that proves the system is back correctly.
• Recovery follows the priorities set in the BCP and DR Procedure and the Information Security Aspects of Business Continuity Policy. Restoration of data must not overwrite evidence needed for an incident investigation until the security operations team releases it.
• Any recovery from backup is recorded with the reason, the data restored, the time taken and the person who verified it.
• After recovery from an attack, systems and credentials are checked for compromise before they return to service.

5.7 Restoration Testing

Failed tests are treated as incidents in the operating process; the cause is found, fixed and the test repeated within [10 working days].

5.8 Network Security Management

The Network Security Procedure gives the technical detail. These statements fix the principles.

5.8.1 Network access

• Access to networks is granted by role on the least-access principle. Every device and user is authenticated before access is given, using certificates, device compliance checks or multi-factor authentication.
• Only Organisation-managed devices may connect to the internal network. Other devices are placed on guest or restricted segments, as set out in the Acceptable Usage Policy.
• Physical network ports in public or meeting areas are disabled, or placed on a restricted segment, unless needed.
• Remote access to the network is through the approved VPN or zero-trust gateway, with multi-factor authentication, device checks and session logging. Split tunnelling is not allowed for devices with Confidential data unless approved.
• Administrators reach management interfaces only from the management network or a hardened jump host. Management interfaces are never exposed to the internet.
• Vendor and maintenance access is enabled only for the period of the work, with an approved ticket, monitored sessions and disabled at completion.

5.8.2 Segmentation and perimeter protection

• Firewalls follow a default-deny rule. Every rule has an owner, a reason, a ticket and an expiry or review date. Rule sets are reviewed [every 6 months] and unused or overbroad rules are removed.
• Intrusion detection or prevention, and a web filter, are placed at the perimeter and between critical segments, and alerts go to the security operations team.
• Network diagrams and addressing plans are kept up to date and protected as Confidential.
• Network devices are configured to the Secure Configuration Policy, with default accounts removed, unused services off, secure management protocols only, and time synchronised.

5.8.3 Internet service and external connections

• Internet connectivity is provided by suppliers whose service levels, security obligations and incident reporting are set out in the contract, as required by the Supplier Relationship Management Policy.
• Critical sites have at least [two] independent internet connections where the business case supports it, and the failover is tested [annually].
• Connections to customers' or suppliers' networks use encrypted tunnels or private links, approved by the Head of IT Security, with the rules recorded in an interconnection agreement.
• Protection against denial-of-service is provided by the supplier or a mitigation service for internet-facing critical platforms.

5.8.4 Wireless access

Wireless networks follow the Acceptable Usage Policy and the Network Security Procedure. Corporate wireless uses strong encryption with individual authentication; guest wireless is isolated from internal networks; unauthorised access points are detected by scans at least [monthly] and removed.

5.8.5 Data in transit

• Confidential and Restricted data is encrypted in transit over any network that the Organisation does not fully control, using the protocols and key strengths in the Cryptography Policy.
• Unencrypted protocols such as telnet, plain file transfer and plain web are not used for administration or for sensitive data.
• Certificates are issued by the approved authority, tracked in an inventory and renewed before expiry, with an alert at [30 days] before expiry.
• Wireless and remote traffic that carries credentials is always encrypted.

5.8.6 Network assessment

Findings are rated, logged and fixed in the periods set in the Vulnerability Assessment and Penetration Testing Procedure and the Patch Management Policy.

5.9 Media Handling

• Removable media is controlled by the Acceptable Usage Policy: blocked by default, issued by the IT function, encrypted, recorded and returned for erasure.
• Media that holds Confidential or Restricted information is labelled with its classification and the owner, stored in locked cabinets or safes when not in use, and moved only by hand or by tracked courier in tamper-evident containers.
• The IT function keeps an inventory of removable media and backup media, checks it [quarterly] and investigates any item that cannot be found.
• Media is sanitised before reuse or disposal using a method that matches the highest classification it ever held (cryptographic erasure, overwrite, degaussing or physical destruction), as set out in the Asset Disposal Process. A certificate or record of sanitisation is kept for each item.
• Disposal of paper follows the shredding standards in the Information Classification and Handling Procedure. Third parties that destroy media must be approved suppliers who supply certificates of destruction.
• System documentation, network diagrams, configuration files and operating procedures are classified at least Confidential, stored with restricted access, and not sent outside the Organisation without approval.
• Information is handled, processed, stored and shared according to its classification. Where media holds mixed classifications, the highest applies.

5.10 Exchange of Information

Information that is exchanged with customers, suppliers, partners and authorities, by any means, must be protected in line with its classification. The Information Classification and Handling Policy defines the levels.

• Before information is exchanged with an external party on a regular basis, an agreement or contract clause must record the information involved, the classification, responsibilities for protection, how it will be sent and received, how incidents are reported, retention and return or destruction, and breach notification. The checklist is in Annexure D.
• Recipients are identified before sending and their authority is verified. Messages to addresses that look new or changed are confirmed on a known telephone number.
• Customer data is exchanged only as the customer contract provides, and on the lawful basis recorded under the Data Protection and Privacy Policy.
• Transfers of personal data outside India or between jurisdictions are made only after the privacy lead has approved them against applicable law in each jurisdiction where the Organisation operates (such as the EU General Data Protection Regulation) and the Digital Personal Data Protection Act, 2023 and its Rules [confirm the current requirement].
• Electronic data interchange, application programming interface links and automated transfers use authenticated, encrypted connections, with credentials rotated at least [every 180 days] and monitored for failure and unusual volume.
• Information must not be left in public places, forgotten in meeting rooms, or discussed within hearing of others.

5.11 Internet Code of Conduct

• Internet access is for business purposes, with personal use limited as the Acceptable Usage Policy sets out. All web access passes through the proxy and the web filter, which blocks malicious and unsuitable categories and records access.
• Users must not download or run software from the internet outside the software catalogue, must not use anonymisers or tunnels to avoid the filter, and must not use peer-to-peer file sharing.
• Users must not post, upload or publish Organisation information, source code, screen images or customer names on any public site, forum, code-sharing site or question-and-answer site without approval from the information owner.
• Users must not enter Organisation credentials on sites other than those the Organisation operates or approves, and must check that a site uses an encrypted connection and a valid certificate before entering any data.
• Users represent the Organisation when they use the internet from its network. They must behave lawfully and professionally, and respect copyright, licence terms and the terms of service of websites.
• Web use is monitored and reports on categories and volumes are reviewed [weekly]. Excessive use or access to blocked categories is raised with the line manager.

5.12 Email and Electronic Messaging

The use of email is governed in full by the Acceptable Usage Policy. For operations, the following rules apply.

• Email, chat and collaboration services are run on approved platforms with anti-malware, anti-spam, sender authentication, data loss controls and logging, and encryption in transit between servers wherever the other side supports it.
• Message size limits, mailbox quotas and attachment restrictions are set by the IT function and published.
• Automatic forwarding to external addresses is disabled. Any exception needs the approval of the Head of IT Security.
• Operators maintain sender authentication records for the Organisation's domains and review reports of failures and spoofing [monthly].
• Messaging systems that carry Confidential data keep logs and archives under the retention rules, and administrators do not read message content except as the Acceptable Usage Policy allows.

5.13 Business Information Systems

• Systems that link business processes, such as office applications, finance, human resources, customer management, and shared calendars, must be assessed for security before connection to each other, including what information flows from one to the other, the access rights in each, and who can see aggregated data.
• Sensitive records, such as legal, personnel and investigation files, must be held in systems with restricted access and not mixed in broad-access folders or shared mailboxes.
• Information on the Organisation's systems must not be uploaded to external services such as online converters, translation or analysis services unless these are approved under the Cloud Computing Security Policy and Procedure.
• Interfaces between systems use named service accounts with least privilege, and the data flows are documented in the system's architecture record.

5.14 Publicly Available Information

• Information is published on public websites, social media, press releases, tenders and repositories only with approval from the information owner and the Head of Communications, after a check that it contains no Confidential or personal data, no internal system details, and no commitments that the Organisation has not agreed.
• Public-facing systems are hosted on hardened infrastructure with integrity controls, change control, and monitoring for defacement and unauthorised changes. Only named people can edit them, using multi-factor authentication.
• Content is reviewed [every 12 months], and out-of-date or incorrect content is removed. Documents are checked for hidden metadata and tracked changes before publication.
• Information collected through public sites, such as forms and cookies, follows the Data Protection and Privacy Policy and the notices shown to individuals.

5.15 Monitoring, Auditing and Logging

Detailed rules are in the Logging and Monitoring Policy and the Logging and Monitoring Procedure. The following apply to operations.

• Logs are sent in real time to a central log service which administrators of the source systems cannot alter. The log service raises an alert if a source stops sending.
• Clocks on all systems are synchronised to the approved time sources, and time differences above [1 second] are investigated.
• Faults and errors reported by users or by systems are logged, analysed and acted on. Where a fault points to a security weakness, it is passed to the security operations team.
• Under the CERT-In Directions of 28 April 2022 [confirm the current requirement], ICT logs must be maintained for 180 days within Indian jurisdiction, and cyber incidents reported within 6 hours of noticing them. The Organisation applies these rules to the logs and incidents within their scope.
• Only authorised staff may access logs, which are protected from alteration and deletion. Access to logs that hold personal data is limited to the purpose of security, operations, audit and investigations.
• Audit activities on production systems are planned with the system owner so that checks do not disrupt operations; auditors have read-only access to tools and data, and the access is removed when the audit ends.

5.16 Protection against Malicious and Mobile Code

The Malware Protection Policy gives the complete rules; the following operate on every system.

• Anti-malware or endpoint detection and response tools run on all servers and endpoints for which a suitable tool exists, with updates and detection data applied within [24 hours] of release, and tampering by users disabled.
• Email, web and file-transfer gateways scan for malicious content before delivery. Attachments that cannot be scanned are held for review.
• Removable media and files from outside are scanned before use. Users cannot run executable code from user-writable locations on managed devices unless the application has been approved.
• Only approved software from the catalogue is installed. Mobile code such as scripts, macros and browser plug-ins is allowed only where it is needed for work, signed or approved, and run in restricted settings.
• Operating systems and applications are patched within the periods in the Patch Management Policy; unsupported software is removed or isolated and recorded as a risk.
• A suspected infection is reported at once. The affected device is isolated from the network by the security operations team, preserved for analysis, and returned to service only after cleaning or re-imaging.
• Regular scans of all assets are run [weekly], and alerts are reviewed within [one working day]. Users are told through awareness training how to spot and report malicious content.

5.17 System Planning and Acceptance

5.17.1 Capacity monitoring and planning

• Each production system has defined capacity measures (for example processor, memory, storage, bandwidth, licences, concurrent sessions) with warning thresholds at [70 percent] and critical thresholds at [85 percent] of the limit.
• Capacity is monitored continuously, reviewed [monthly] by the system administrators, and forecast for the next [12 months] using trends and business plans, as set out in the Capacity Management and Planning Procedure.
• Capacity shortfalls and projected growth are reported to the system owner and budgeted. Resources that take long to procure are ordered in advance.
• Tests of load and failover are run before major launches, and after changes that may alter capacity.

5.17.2 System acceptance

A new system, a major upgrade or a new version is not put into production until it has been accepted using the criteria below and the checklist in Annexure C.

• Acceptance is decided by the system owner and the Head of IT Operations, with the Head of IT Security signing the security criteria. Open issues are recorded with an owner and date.
• Systems that fail acceptance are not released, or are released only with a written risk acceptance that has a closing date.

6. Compliance and Monitoring

Results are included in the report to senior management in the management review. Repeated failure of a control leads to a corrective action under the Information Security Monitoring and Compliance Policy.

7. Records and Evidence

Records are protected from alteration and are available to auditors and to customers who have the right to see them under contract.

8. Where the Detail Is Kept

• Network Security Procedure: network design, access and rule management.
• Backup and Restoration Policy and Backup Management and Retention Procedure: schedules, retention and testing in full.
• Change Management Policy and Procedure: change process, approval and emergency changes.
• Logging and Monitoring Policy and Logging and Monitoring Procedure: events, review and retention of logs.
• Malware Protection Policy and Patch Management Policy: detection, response and patching.
• Capacity Management and Planning Procedure: capacity measurement and forecasting.
• Information Classification and Handling Policy: the classification used for exchange and handling.
• Acceptable Usage Policy: user rules for email, internet, media and wireless.

Annexure A: Change request form

Annexure B: Backup restoration test record

Annexure C: System acceptance checklist

Annexure D: Information exchange agreement checklist

Annexure E: Network rule review record

9. 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.

10. 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.

11. 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 27001:2022 references

Related documents

• Network Security Procedure
• Backup and Restoration Policy
• Change Management Policy and Procedure
• Logging and Monitoring Policy
• Malware Protection Policy
• Acceptable Usage Policy
• Capacity Management and Planning Procedure
• Information Classification and Handling Policy