Template draft. Replace everything in [square brackets] with your own decision,
delete what does not describe what you really do, and approve it through your own document control. It is not legal
advice and does not make an organisation compliant or certified.
1. Introduction
Every service the Organisation provides depends on information that must stay confidential, accurate and available. This procedure shows how information security is built into the way services are designed, run, changed and bought, so that service management and the information security management system work as one set of controls and not two parallel ones.
It does not replace the information security policies and procedures. It states which of them apply to a service, who is accountable for applying them, and how evidence is produced for the customer.
2. Purpose
This procedure ensures that each service has a documented security policy and requirements, that controls are chosen from a risk assessment and not by habit, that access to service systems and data is controlled and reviewed, that security incidents are handled in step with service incidents, and that changes and suppliers do not weaken security. It also makes clear how the service management system relies on the Organisation's ISO/IEC 27001-aligned documents.
3. Objectives
- Hold a service security policy and a written set of security requirements for every service in the catalogue.
- Assess information security risks to each service when it is designed, when it changes materially, and at least every [12 months].
- Apply the controls selected for the service and show evidence that they work.
- Review access to service systems and data at the frequencies in this procedure, with [100%] of reviews completed on time.
- Handle every security event that touches a service as both a security matter and a service matter, with one coordinated record.
- Assess every change and every supplier for security effect before approval.
- Report security measures for services to the customer and to top management each [quarter].
4. Scope
- In scope: all services in the service catalogue, including customer-facing platforms, internal services and services provided by suppliers on the Organisation's behalf.
- In scope: the information, applications, infrastructure, networks, endpoints, people and sites that deliver those services.
- Out of scope: the wider information security management system, which is governed by the Information Security Policy and its related documents, and security of products the Organisation does not operate.
- Applies to: service owners, the information security manager, technical teams, the service desk, the change authority, the supplier manager, and any person with access to service systems.
5. Terms and definitions
| Term | Meaning |
|---|
| Service security policy | A short statement for a service that sets its security objectives, classification and controls, approved by the service owner. |
| Security requirement | A need for confidentiality, integrity, availability or privacy that comes from a customer, law, contract or risk assessment. |
| Security event | An occurrence that may indicate a breach of policy or failure of a control. |
| Security incident | A security event that is confirmed or likely to harm information, a service or a person. |
| Control | A measure that reduces risk, such as a technical setting, a process step or a rule. |
| Residual risk | The risk that remains after controls are applied. |
| Least privilege | Giving a person only the access needed to do their work, for only as long as needed. |
6. Roles and Responsibilities
| Role | Responsibilities |
|---|
| Top management | Approves the information security policy and the resources for it, and receives the quarterly security report for services. |
| Process owner (Information Security Manager) | Owns this procedure, sets the requirements template, runs risk assessments with service owners and reports. |
| Service owner | Accountable for the security of the service: approves the service security policy, accepts residual risk within authority, and ensures controls are operated. |
| Process manager (Security Operations lead) | Operates monitoring, handles security events, and works with the service desk on incidents. |
| Technical teams | Implement and operate security controls in the service, apply patches and configurations, and provide evidence. |
| Service desk | Recognises and passes on security events, enforces identity checks and access request rules. |
| Change authority | Includes a security assessment in every change decision and refuses changes that raise risk beyond appetite. |
| Supplier manager | Applies security requirements in supplier selection, contracts, monitoring and exit. |
| Customer representative | Gathers customer security requirements and reports security status to the customer. |
| All personnel | Follow the Acceptable Usage Policy, complete awareness training, and report security events at once. |
| Activity | Responsible | Accountable | Consulted | Informed |
|---|
| Set service security policy and requirements | Service owner | Information security manager | Technical teams, Customer representative | Top management |
| Assess risks and select controls | Information security manager | Service owner | Technical teams | Top management |
| Operate and evidence controls | Technical teams | Service owner | Information security manager | Process manager |
| Manage access to service systems | Technical teams | Service owner | Information security manager, Line managers | Service desk |
| Handle security incidents | Process manager | Information security manager | Service owner, Service desk | Top management, Customer representative |
| Assess security in changes | Information security manager | Change authority | Technical teams | Service owner |
| Assess and monitor supplier security | Supplier manager | Information security manager | Service owner | Top management |
| Report security measures | Information security manager | Top management | Service owners | Customer representative |
7. Information Security Management Process
7.1 Inputs and outputs
| Inputs | Outputs |
|---|
| Information security policy and the security documents of the information security management system | Service security policy and requirements for each service |
| Customer contracts, laws and regulatory duties | Risk assessment and treatment plan per service |
| Service catalogue, design documents and architecture | Controls applied with evidence of operation |
| Threat intelligence, vulnerability scans and audit findings | Access review records |
| Security events and incidents | Security incident records linked to service incident records |
| Change and supplier proposals | Security assessments for changes and suppliers, and quarterly reports |
7.2 Service security policy
Each service has a service security policy of no more than [two pages], approved by the service owner and kept with the service record. It applies the Information Security Policy to the service and is reviewed every [12 months] or on material change.
| Section | Content |
|---|
| Purpose and customers | What the service does and who relies on it |
| Information handled | Types of data, their classification under the Information Classification and Handling Policy, and any personal data |
| Security objectives | Confidentiality, integrity, availability and privacy goals, with measures |
| Legal and contractual duties | Contractual security terms, customer audit rights and applicable law |
| Controls | The controls selected and their owners, with reference to the Statement of Applicability |
| Access rules | Who may access what, privileged access rules and review frequency |
| Incident and recovery arrangements | Reporting route, contacts, recovery tier and links to the continuity plan |
| Approval and review | Approver, date and next review |
7.3 Risk assessment and control selection
- Identify assets and threatsWith the service owner, the information security manager lists the information assets, systems, suppliers and people in the service, and the threats and weaknesses that matter, drawing on threat intelligence and past incidents.
- Rate the riskEach risk is rated using the method in the Risk Management Policy, for likelihood and impact on confidentiality, integrity, availability and privacy.
- Choose treatmentFor each risk above the acceptance threshold, the owner chooses to reduce, transfer, avoid or accept. Reduction means selecting controls from the Statement of Applicability or adding new ones.
- Record and approveTreatment actions, owners and dates go into the risk register. Residual risk is accepted only by the person whose authority covers its rating, as shown in the table below.
- ReviewThe assessment is repeated every [12 months], after a significant incident, and before a material change or a new supplier.
| Residual risk rating | Accepted by | Review of acceptance |
|---|
| Low | Service owner | [12 months] |
| Medium | Service owner and information security manager | [6 months] |
| High | Top management | [3 months] |
| Critical | Not accepted; treatment is required, with top management informed within [2 business days] | Until reduced |
7.4 Controls applied to services
The table shows controls normally applied to services and the document in which each is set out. A control may be scaled to the service's classification; an exemption is made through the exception process and recorded.
| Control area | Requirement for services | Where it is set out |
|---|
| Governance and risk | Security policy, roles and risk assessment per service | Information Security Policy; Risk Management Policy |
| Access and identity | Least privilege, strong authentication, joiner-mover-leaver, periodic review | Access Control Policy; User Access Management Procedure |
| Data protection | Classification, handling, retention and privacy by design for personal data | Information Classification and Handling Policy; Data Protection and Privacy Policy |
| Cryptography | Encryption in transit and at rest, key management | Cryptography Policy; Key Management Process |
| Operations | Hardened configuration, malware protection, patching, capacity and backup | Secure Configuration Policy; Malware Protection Policy; Patch Management Policy; Backup and Restoration Policy |
| Monitoring and detection | Logging of security-relevant events, review and alerting | Logging and Monitoring Policy; Logging and Monitoring Procedure |
| Vulnerability management | Scanning and testing at the frequencies below, with fix times | Vulnerability Assessment and Penetration Testing Procedure |
| Incident response | Detection, triage, containment, evidence and reporting | Information Security Incident Management Policy; Incident Management Procedure |
| Change and development | Security assessment in change, secure development and testing | Change Management Policy and Procedure; System Development and Maintenance Procedure |
| Suppliers and cloud | Due diligence, security terms and monitoring | Supplier Relationship Management Policy; Cloud Computing Security Policy and Procedure |
| Continuity | Security controls remain in force during recovery | Information Security Aspects of Business Continuity Policy; BCP and DR Procedure |
| People and physical | Screening, awareness, physical protection of sites and equipment | HR Security Policy; Physical and Environmental Controls Policy |
| Activity | Tier 1 services | Tier 2 services | Tier 3 and 4 services |
|---|
| Vulnerability scan | [Weekly] | [Monthly] | [Quarterly] |
| Penetration test | [Every 12 months and after major change] | [Every 18 months] | [On risk] |
| Critical patch applied | [Within 7 days] | [Within 14 days] | [Within 30 days] |
| Access review | [Every 3 months] | [Every 6 months] | [Every 12 months] |
| Log retention | [12 months, ICT logs 180 days within India as required] | [12 months] | [6 months] |
| Backup restore test | [Every month] | [Every 6 months] | [Every 12 months] |
7.5 Access to service systems and data
- RequestAccess is requested through the Service Request Management Procedure on the catalogue form, naming the service, role and reason.
- ApproveThe line manager and the system or data owner approve. Privileged access also needs the information security manager, and is time-limited to [12 months] or the task.
- ProvideThe identity team grants the access, using individual accounts and multi-factor authentication. Shared and generic accounts are not permitted, except where recorded as an exception with named custodians.
- ReviewOwners review access at the frequency in the table above and remove what is not needed within [5 business days]. Privileged access and third-party access are reviewed every [3 months].
- RemoveAccess ends on the last working day of a leaver, on role change within [5 business days], and when a supplier contract ends. The identity team records the removal.
- MonitorPrivileged sessions and access to restricted data are logged and sampled by security operations every [month].
Note. Access for customers or their staff to the service is managed through the customer's own authorised contacts, listed in the service agreement, and reviewed each [6 months] with the customer representative.
7.6 Security incidents and events
A security event reported to the service desk is logged as an incident under the Service Incident Management Procedure and passed to security operations within [15 minutes]. Security operations leads the security response under the Incident Management Procedure and the Information Security Incident Management Policy; the service desk continues to manage service impact and communication.
| Event | Who leads | First action | Time |
|---|
| Suspected malware or intrusion | Security operations | Isolate the affected system; preserve evidence | [Within 30 minutes] |
| Suspected exposure of personal or customer data | Information security manager with the data protection lead | Contain; assess scope; decide notifications | [Within 1 hour] |
| Phishing reported by a user | Security operations | Block sender and links; check for other recipients | [Within 1 hour] |
| Loss or theft of a device | Service desk and security operations | Remote lock or wipe; revoke tokens | [Within 1 hour] |
| Attack that degrades the service | Major incident manager and security operations | Apply the major incident process with security containment | [Within 15 minutes] |
The CERT-In Directions of 28 April 2022 require cyber incidents to be reported within 6 hours of noticing, and ICT logs to be kept for 180 days within Indian jurisdiction [confirm the current requirement]. The Digital Personal Data Protection Act, 2023 and its Rules set duties on personal data breaches [confirm the current requirement]. The information security manager decides, with legal advice, whether and what to report, and records the decision. Each security incident record is linked to its service incident record, and the lessons are fed into problem management.
7.7 Change and release security
- Every request for change includes a security assessment. The information security manager is consulted on changes to authentication, network boundaries, encryption, logging, personal data flows and new suppliers.
- Changes are classified for security risk. High-risk changes need the information security manager's sign-off before the change authority decides.
- Security testing, such as code review, scanning or a penetration test, is completed before release for Tier 1 and Tier 2 services, and results are attached to the change.
- Emergency changes are reviewed for security within [2 business days] after implementation.
- Test data is not production data. Where production data must be used, it is masked or approved by the data owner and protected as in production.
- Separate environments and separate duties are kept for development, testing and production access.
7.8 Supplier and cloud security
Suppliers that process, store or can access service information are assessed before award and again each [12 months]. Assessments follow the Supplier Relationship Management Policy and the Supplier Management Procedure; the points below apply to every such supplier.
- Contracts state security requirements, data handling and return, incident notification within [24 hours], audit rights and flow-down to subcontractors.
- The supplier's evidence of controls, such as an independent report or certificate, is reviewed by the information security manager and its scope checked against the service used.
- The supplier's access to Organisation systems is limited, logged and reviewed every [3 months].
- Cloud services follow the Cloud Computing Security Policy and Procedure, including configuration baselines and clear division of responsibility.
- At exit, access is removed, data is returned or deleted with written confirmation, and keys are rotated.
7.9 Monitoring, measurement and reporting
- CollectSecurity operations collects the measures in the KPI table from tools and records.
- ReviewThe information security manager reviews results with each service owner every [month], and with top management each [quarter].
- ReportCustomers receive the security measures their agreement promises, through the customer representative, as part of the service report.
- ImproveGaps become actions in the improvement register under the Service Reporting and Continual Improvement Procedure.
7.10 Process flow
- Information Security Policy and the service's legal and contract duties set the security requirements.
- Service owner and information security manager write the service security policy.
- Risk assessment identifies risks, controls are selected from the Statement of Applicability, and residual risk is accepted at the correct level.
- Technical teams implement the controls; access is granted and reviewed under the access rules.
- Changes and suppliers are assessed for security before approval.
- Security operations monitors, detects and handles events with the service desk.
- Measures are reviewed monthly and reported quarterly; findings go to improvement actions.
- The assessment and policy are refreshed every year or on material change.
8. Interfaces with Other Processes
| Process | Interface |
|---|
| Service Incident Management Procedure | Security events are logged and coordinated as incidents; security operations leads the security response. |
| Service Request Management Procedure | Access and data requests carry the approvals defined here. |
| Change Management Procedure | Security assessment is a required step in every change. |
| Supplier Management Procedure | Security due diligence, terms and monitoring for suppliers. |
| Configuration and Asset Management Procedure | Asset and configuration records show what to protect and the classification of each. |
| Availability and Service Continuity Management Procedure | Security in recovery; protection of backups and alternate sites. |
| Service Design and Transition Procedure | Security requirements are set in design and tested before go-live. |
| Service Reporting and Continual Improvement Procedure | Security measures and improvement actions. |
9. Key Performance Indicators
| Measure | Target | Source | Frequency |
|---|
| Services with an approved service security policy | [100%] | Service catalogue | [Quarterly] |
| Services with a risk assessment less than 12 months old | [100%] | Risk register | [Quarterly] |
| Critical vulnerabilities fixed within the target for the tier | [95%] | Vulnerability scanner | [Monthly] |
| Access reviews completed on time | [100%] | Access review records | [Quarterly] |
| Leavers whose access was removed on the last working day | [100%] | Identity records | [Monthly] |
| Changes with a recorded security assessment | [100%] | Change records | [Monthly] |
| Security events passed to security operations within 15 minutes | [95%] | Incident records | [Monthly] |
| Suppliers with a current security assessment | [100% of in-scope suppliers] | Supplier register | [Annually] |
| Residual risks accepted within authority and not past expiry | [100%] | Risk register | [Quarterly] |
10. Records and Evidence
| Record | Kept in | Retention |
|---|
| Service security policies and requirements | [Service catalogue repository] | [Life of the service plus 3 years] |
| Risk assessments, treatment plans and acceptances | [Risk register] | [Until reviewed, then 5 years] |
| Access requests, approvals and review records | [The ticketing tool and identity system] | [3 years] |
| Security incident records linked to service incidents | [The ticketing tool] | [5 years] |
| Change security assessments and test results | [The ticketing tool] | [3 years] |
| Supplier assessments and security evidence | [Supplier file] | [Contract term plus 3 years] |
| Quarterly security reports | [Document management system] | [3 years] |
Annexure A: Service security requirements
| Item | Entry |
|---|
| Service name and owner | |
| Classification of information handled | |
| Personal data processed (yes or no, type) | |
| Customer or legal security duties | |
| Confidentiality requirement | |
| Integrity requirement | |
| Availability requirement and tier | |
| Access model and privileged roles | |
| Controls selected and owners | |
| Residual risk rating and acceptor | |
| Approved by and date | |
| Next review date | |
Annexure B: Change security assessment
| Question | Answer |
|---|
| Change reference and title | |
| Does the change touch authentication, network boundary, encryption or logging? | |
| Does it alter personal data collection, storage or sharing? | |
| Does it introduce a new supplier or tool? | |
| Security tests planned or completed | |
| Risks identified and controls added | |
| Security risk rating (low, medium, high) | |
| Assessed by and date | |
| Decision | |
Annexure C: Access review record
| Service | Reviewer | Review date | Accounts reviewed | Removed or changed | Exceptions noted | Sign-off |
|---|
| | | | | | |
| | | | | | |
| | | | | | |
Annexure: Document history
| Version | Date | Author | Summary of change | Approved by |
|---|
| 1.0 | [dd-mm-yyyy] | [Author] | Initial issue from the SecureXcel template | [Approver] |
| | | | |
| | | | |
11. 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.
12. 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.
13. 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
| Reference | Title |
|---|
| 8.7.3 | Information security management |
| 6.1 | Actions to address risks and opportunities |
| 5.2 | Policy |
| 8.1 | Operational planning and control |
| 8.3.4 | Supplier management |