Logical Access Control Policy

Contents

1. Scope

2 . Purpose

3. Terms and definitions

4. Responsibilities

7. Reference

1. SCOPE:

This policy applies to all information, information assets, information systems and information processing facilities of Vishvas news.

2. PURPOSE:

The purpose of this policy is to define the rules for provisioning and revocation of accesses for   various information, information assets, information systems as well as information processing facilities of Vishvas news.

3. TERMS AND DEFINITIONS:

Following is an explanation of various terms used within this document –

4. RESPONSIBILITY 

• The primary ownership of implementing this Policy is with the Information Security Officer.
  
• The Information Security Officer shall implement this Procedure under guidance of the Leadership Team and in coordination with Function Heads.

5. POLICY

5.1 Access Control

• Access control shall cover all types and forms of information assets and information systems, used within Vishvas news. Access control shall apply to below listed information assets and information systems – 

• Vishvas news Application on Cloud
• Cloud Environment – GCP
• Google Workspace
• Development and Testing Environment
• Code Repository
• Other Information Systems used within Vishvas news
• Networking Devices such as Firewall / Router etc.
• All access requests shall be approved by the Head of concerned Department.
• Access shall be provided on a need-to-know basis.
• Access provisioning to external people, entities or Vishvas news shall be controlled and appropriately approved.

5.2 Access Provisioning

• Access provisioning requests shall be managed through Email or Ticketing Tool approvals from Reporting Managers or Head of Departments.

• Shared or Common access shall be avoided, unless justified by business purpose. Such exceptions shall be approved by the Information Security Officer.
• All User level access shall be secured through username and passwords.
• Administrative or Privilege access shall be controlled through Multi-Factor Authentication, wherever possible.
• All Access provisioning records, and status shall be maintained and updated within Access Control Matrix.

5.3 Access Revocation

• Access shall be revoked immediately when the User separates from the Vishvas news or no longer needs to have the access.
• Access shall also be revoked or changed whenever any User changes the role or function.
• Access revocation records shall be maintained within Email or Ticketing Tool.

5.4 Access Review

• Access reviews shall be conducted on a periodical basis to ensure adequacy. The planned frequency of conducting all types of Access Reviews shall be Half yearly.
• Access reviews shall be conducted against the provisioned access and against Access Control Matrix maintained.
• Any access which is found to be no longer required, shall be adjusted, or revoked.
• Records of access review shall be maintained for further reference.

6. PROCEDURE:

6.1 Access Provisioning Process

• Access provisioning requests shall be initiated by the HR Team for the newly joined Users (Employees / Non-Employees) at the time of joining.
• Access provisioning requests may also be initiated by existing Users for having access to any new Information System or Application to which they do not have access presently.
• All Access requests should be initiated through Email or Ticketing Tool.
• HR Team or User shall raise the Access request within Email and Head – HR or the Reporting Manager shall approve the same.

• For User requests of access, the Email or Ticketing Tool request shall be approved by the Head of department.
• For any Administrative level access request, raised through Email or Ticketing Tool, the approval shall be done by the Information Security Officer.
• Email or Ticketing Tool Requests, duly approved, shall be forwarded / assigned to the respective Teams for provisioning of access.
• The Access provisioning responsibilities are as below –

---

Password Management Policy

 Contents

1. Scope

2 . Purpose

3. Terms and definitions

4. Responsibilities

5. Policy

6. Procedure

• 6.1 Password Creation Procedure
• 6.2 Password Modification Procedure
• 6.3 Password Reset Procedure
• 6.4 Password Protection Guidelines
• 6.5 Protection of Super user Password / Administrator Password
• 6.6 In case of separation of an employee
• 6.7 User Responsibilities

7. REFERENCES:

1. SCOPE

The scope of this policy includes all personnel who have or are responsible for an account (or any form of access that supports or requires a password) on any system and supporting facilities of the organization.

This procedure is applicable to all the users who create and use passwords to access Organization Information and IT assets.

2. PURPOSE

The purpose of this Policy is to define the rules and guidelines for password management mechanisms within an organization.

The purpose of this procedure is to implement a password management mechanism in accordance with Password Policy.

3. TERMS AND DEFINITIONS

Following is an explanation of various terms and abbreviations used within this document – 

• ISMS : Information Security Management System
• LT : Leadership Team
• Information Security officer : Person who heading the ISMS Activities
  

4. RESPONSIBILITIES

• The primary ownership of implementing this Policy is with the IT Function Head.
• The ISMS Head shall implement this Procedure under guidance of the Leadership Team and in co-ordination with Function Heads.

5. POLICY

• There shall be a formal Procedure for Password Management in Organization which shall be strictly adhered to by all users of information and IT assets of Organization.
• This procedure shall be system controlled, wherever technically possible. 
• IT shall develop and implement administrative procedures to create, change, reset and subsequently communicate initial passwords to the concerned users.  
• Wherever technically feasible, a control shall be enforced to change temporary password at first logon by the concerned user.
• System Administrator shall ensure to change all default passwords provided by Vendors.
• Passwords shall not be stored on computer systems in an unprotected form.
• IT System Administrator shall determine and enforce appropriate controls to

• Ensure the use of passwords with complexity
• Change passwords at predefined frequency
• Prevent reuse of old passwords for predefined iterations

• The use of password by more than one user (Sharing of password) is discouraged in Organization. However, sharing of password for a legitimate business reason shall be allowed after appropriate authorization received from Head – IT Function. 
• Use of Group user-id/ password shall be limited to situations dictated by operational necessity and/or under certain circumstances approved by Head – IT Function. 
• All the systems, applications shall adhere to password policy.

6. PROCEDURE:

6.1 Password Creation Procedure

• Passwords used shall be of minimum 8 characters. 
• Password and User Id shall not be identical.
• A password shall be different from previous three (3) passwords.
• For new joiners, after creation of id in user’s system default password would be shared with the user and prompted to change the password on first login.

6.2 Password Modification Procedure

Users shall modify/change their passwords using password change option provided with the system, in accordance with the password guidelines.

6.3 Password Reset Procedure

• If a user is unable to recollect his/her current password, then he/she will initiate a request to reset the password through email / phone or notification.
• IT Function will reset the password to predefined default password and enable the setting for prompting the user to change password at first log-on.
• The records of password reset shall be maintained.

6.4 Password Protection Guidelines

• Passwords during the user creation process must be changed at the first Logon. This applies to all user-ids and E-mail ids.
• Use of a single password shall be avoided to access various Organization’s information / IT systems. (Ex. Active Directory Systems)
• Details in relation to User ID & password etc. should not be sent using clear text across mail systems/ SMS.
• Passwords shall not be revealed to anyone orally in person/ phone/ mobile sets or through fax /Internet messenger services.
• Passwords shall be encrypted when stored in files or databases or transmitted over the Internet, public networks or wireless devices. Where encryption is not possible, access to such files/databases shall be restricted.
• Format of a password shall not be revealed without authorization.
• Passwords shall not be revealed on questionnaires or security forms.
• Passwords shall not be shared with family members and co-workers.
• “Remember password” feature of applications shall not be used.
• Passwords shall not be written down and stored anywhere inside and outside the Organization. 
• Users shall log out when leaving their desk for extended periods of time. Especially administrative users with extended rights
• If an account or password is compromised, the password must be changed immediately.

6.5 Protection of Super user Password / Administrator Password

• All super user/ administrator passwords of critical servers & critical devices should be sealed in an envelope and kept in lock & key with Head-IT.
• This will aid in retrieval of administrator password if password is forgotten or the concerned person has left without surrendering passwords.
• In case password needs to be retrieved from the sealed envelope, it should be changed immediately, and the new sealed envelope shall be kept with Head-IT as per Sealed hard copy of administrative password.
• In case a person holding administrator / super user password resigns, the password should be changed immediately and stored in a new sealed envelope and kept with Head-IT.

6.6 In case of separation of an employee

• Passwords for all accounts and possibly the user ID must be changed on separation / resignation of employees from the IT Function.
• For other categories of employees, the relevant accounts must be disabled / removed.
• If user ID is required after separation of an employee, concerned Function Head should request for keeping the ID live and change of password. The Function Head should also intimate who needs to have the new password.

6.7 User Responsibilities

Do’s:

• ALWAYS USE passwords of following types:

• Contain both upper- and lower-case characters (e.g., a-z, A-Z)
• Are at least eight characters long.
• Passwords that can be easily remembered. 
• One way to do this is create a password based on a song title, affirmation, or other phrase. For example, the phrase might be: “This May Be One Way to Remember” and the password could be: “TmB1w2R!” or “Tmb1W>r~” or some other variation.
• Use English spellings for words / songs in your mother tongue.

 Don’ts:

• DO NOT USE following types of passwords:

• Passwords based on personal information, names of family members, etc.
• Password, which is a word in any language, slang, dialect, jargon, or found in a dictionary.
• Never write down passwords or store them on-line.
• Password containing less than seven characters.
• Never use a password which is a commonly used word such as names of family members, pets, friends, co-workers, fantasy characters, etc.
• Computer terms and names, commands, sites, companies, hardware, software.
• The words “FWSPL” or any derivation.
• Birthdays and other personal information such as extension or phone numbers.
• Word or number patterns like aaabbb, gfedcba, 123321, etc.
• Do not use either of these examples as passwords.

7. REFERENCES:

Password Creation / Change records

---

Data & Records Retention Policy

1. Scope

2 . Purpose

3. Terms and definitions

4. Responsibilities

1. Scope

2 . Purpose

3. Terms and definitions

4. Responsibilities

---

Key Management Policy

1. Scope

2 . Purpose

3. Definitions

4. Responsibilities

7. Reference

1. SCOPE

This procedure applies to management of all types of Cryptographic Keys used within Vishvas news.

2. PURPOSE

The purpose is to define the process for generation, acquisition, inventorying, allocation, de-allocation and disposal of Cryptographic Keys used within Vishvas news.

Definitions

Following is an explanation of various terms used within this document – 

• Cryptography : Is a technique of securing information and communications through use of codes so that only those persons, for whom the information is intended, can understand it and process it, thus preventing unauthorized access to information. Features of cryptography include Confidentiality, Integrity, Non-repudiation and Authentication.
• Key :   In cryptography, a key is a piece of information (a parameter) that determines the functional output of a cryptographic algorithm. For encryption algorithms, a key specifies the transformation of plaintext into cipher text, and vice versa for decryption algorithms.
• Digital Certificate :  A Digital Certificate is an electronic “password” that allows a person, organization to exchange data securely over the Internet using the public key infrastructure (PKI). Digital Certificate is also known as a public key certificate or identity certificate. Digital certificate is a file that ensures holder’s identity and provides security. It is generated by CA (Certifying Authority) and follows X.509 standard format.

• Digital Signature :  Digital signature is used to verify authenticity, integrity, non-repudiation i.e., it is assuring that the message is sent by the known user and not modified. Hashed value of original message is encrypted with sender’s secret key to generate the digital signature. It follows Digital Signature Standard (DSS).
• VPN : Virtual Private Network – A virtual private network (VPN) is a technology that creates a safe and encrypted connection over a less secure network, such as the internet. It makes use of tunneling protocols to establish a secure connection.
• LT : Leadership Team
• Information Security  Officer :    Person heading the ISMS Activities

4. RESPONSIBILITIES

• The primary ownership of implementing this Policy is with IT.
• The IT Team shall implement this Policy under guidance of Leadership Team and in co-ordination with Function Heads.

5. POLICY

5.1 Key Generation or Acquisition

•   Below types of Cryptographic Keys may be used within Vishvas news – 

Cryptographic Key	Usage
SSL Certificate	Vishvas news Website,Vishvas news Domain,
TLS / SSL Encryption	Emails
Digital Signatures (Tokens)	Compliance and Return Filing
Authentication Tokens	GCP Admin Access User Access
VPN Encryption Key	Users connecting to Vishvas news Servers
Bit-Locker Encryption	Encryption of Laptops

• Keys shall be either generated by Vishvas news using servers and systems or procured from third party Certificate Authority (CA).

• All Keys generated or procured shall be inventoried using Asset Inventory. The inventorying should include minimum information about –

• Key Name, Identification
• Details of Certificate Authority (CA) if procured from CA.
• Date of Generation / Procurement
• Validity of Key / Expiry Date
• Name of Person / Function who had the custody of the Key

• Retention or Validity period for each type of Key shall be identified and applied to keys in possession of Vishvas news.
• The expired keys shall be either returned back to vendor or CA or disposed / deleted using secure methods.
• Records of Key returning to Vendor / CA or disposal shall be maintained for audit and reference purpose.
• Requirements for secure storage, handling and retention of Keys shall be identified and defined for each type of Keys.

5.2 Key Inventorying and Allocation

• All types of cryptographic controls and keys shall be inventoried within Asset Inventory.
• Keys shall be allocated to Information Systems or Users and records shall be maintained 
• Appropriate approvals shall be procured before allocating / handing over the keys to user / Function.
• For each of the Key issued or allocated, Custodian shall be identified and assigned within Asset Inventory.
• Keys, when required to be stored, shall be protected from unauthorized access or alternation or tampering.

5.3 Key De-Allocation and Disposal

• A Key, when expired or no longer required, shall be de-allocated from the information systems.
• Expired or De-Allocated Keys shall be collected back and either returned to Certifying Authority or disposed securely.
• Records of return of disposal of Keys shall be maintained.

6. PROCEDURE

6.1 SSL Certificate Process
To procure SSL Certificate from Certificate Authority (CA)

• Set the OpenSSL configuration environment variable

• Open the Command Prompt as an administrator
• Run the following command:
  Set OPENSSL_CONF=<server_path>\packages\apache.<version_code>\conf\openssl.cnf

• Generate a Key

• Open the Command Prompt as an administrator,
• Navigate to the Apache directory for Server. For example, run the following command:
  cd <path>\apache.<version_code>\bin
• Run the following command to create the key file:
  openssl.exe genrsa -out <yourcertname>.key 4096
• This command uses a 4096-bit length for the key. Bit length should be chosen at least 2048 bits to ensure adequate
• If a value is not provided, default 512 bits is used.security of communication.

• Create a Certificate Signing Request (CSR) to send to a Certificate Authority (CA)

• Use the key file you created in the procedure above to generate the certificate signing request (CSR). 
• Run the following command to create a certificate signing request (CSR) file:
  openssl.exe req -new -key yourcertname.key -out yourcertname.csr
• When prompted, enter the required information.

• Send the CSR to CA to obtain an SSL Certificate

• Send the CSR to a commercial certificate authority (CA) to request the digital certificate.
• For more information about CA, please refer –
  https://en.wikipedia.org/wiki/Certificate_authority

• Use the Key and Certificate to configure Server

• When you have both the key and the certificate from the CA, you can configure Server to use SSL.
• For configuring SSL on Server, help can be taken from the respective Server knowledge base. E.g. – For configuring SSL on Tableau Server –
  https://help.tableau.com/current/server/en-us/ssl_config.htm 
• In addition to the certificate file, you must also acquire a corresponding SSL certificate key file. The key file must be a valid RSA or DSA private key file (with the extension .key by convention).
• You can choose to passphrase-protect the key file. The passphrase you enter during configuration will be encrypted while at rest.
• For multiple sub-domains, Servers supports wildcard certificates.
• After the server has been configured for SSL, it accepts requests to the non-SSL port (default is port 80) and automatically redirects to the SSL port.

6.2 To create own SSL Certificate
Procedure to create own SSL Certificate using IIS in Windows Server However this is not our case.

• To Create the SSL Certificate

• Click on the Windows icon in the taskbar,
• Search for IIS,
• Open Internet Information Services (IIS) Manager.
• Click on the name of the server in the Connections column on the left.
• Double click the Server Certificates icon.
• In the Actions column on the right hand side, click on Create Self Signed Certificate.
• Enter the friendly name you wish to use to identify the certificate, and then click OK.
• You now have an IIS Self Signed Certificate, valid for one year, which will be listed under Server Certificates. The common name is the server name.

• To bind the Self Signed Certificate

• Browse to the connections column on the left-hand side, expand the sites folder and click on the website to which you wish to bind the SSL certificate to.
• Once it is done, on the right-hand side, click on Bindings in the Actions column.
• Click the Add… button. 
• Click the Type drop down menu. Select https
• Click on the SSL Certificate drop down, choose the newly created SSL certificate.
• Click OK.
• You should now see the bindings for port 443.
• You can now on click Close.
• To test the new Self Signed SSL Certificate, open up a browser, and go to the website.
• If the certificate has been installed and created correctly, depending on the browser you are using, you will see a lock icon next to the URL, or it will say Secure.

6.3 Procedure to create own SSL Certificate using Linux Server

• Please refer the tutorial on the links below for creating self-signed SSL Certificates for Apache on Linux

https://www.linux.com/training-tutorials/creating-self-signed-ssl-certificates-apache-linux/
https://www.rosehosting.com/blog/how-to-generate-a-self-signed-ssl-certificate-on-linux/

6.4 VPN Process

Procedure for generating OpenVPN Certificates and Keys

• Please refer –
  https://help.yeastar.com/en/s-series/topic/openvpn-generate-certificates-and-keys.html

Procedure for configuring a VPN using Easy VPN and IPSEC Tunnel

• Please refer – 
  https://www.cisco.com/en/US/docs/routers/access/800/850/software/configuration/guide/vpnezvpn.html

6.5 Laptop Encryption Process

Encrypting Windows Laptop using BitLocker

• Please refer –
  https://www.windowscentral.com/how-use-bitlocker-encryption-windows-10

Encrypting Linux Laptop

• Please refer – 
  https://www.cyberciti.biz/hardware/howto-linux-hard-disk-encryption-with-luks-cryptsetup-command/

Encrypting Apple Laptop using File Vault

• Please refer – 
  https://support.apple.com/en-in/guide/mac-help/mh11785/mac

6.6. Digital Signature Process

• The Digital Signatures can be procured from Certificate Authority (CA) as applicable.
• You can verify the authenticity of the CA by referring their information on Ministry of Corporate Affairs (MCA) Website in India.
• The Digital Signature Certificate (DSC) and USB Token will be provided by CA.
• For process of using the DSC, please refer – 
  https://cleartax.in/s/how-to-use-a-digital-signature-certificate

7. REFERENCE

• Template – Asset Inventory
• Policy – Asset Management
• Policy – Key Management
• Records of Key Generation, Storage, Allocation, De-Allocation and Disposal.

---

Incident Response Plan

1 . PURPOSE

2 . SCOPE

3. ABBREVIATIONS AND DEFINITIONS

4. RESPONSIBILITIES

7. Reference

1. PURPOSE

• The purpose of this policy is to provide guidelines and plan for responding to various information security and personal data related incidents and breaches.

2. SCOPE

• This policy applies to the Information, Information Assets, Information Systems, Information Processing Facilities, Networks and any person or device gaining access to the systems and data at Vishvas news.
  
  This plan applies to personal data or personally identifiable information (PII), belonging to Vishvas news or their clients or data subjects, which is acquired, stored, processed, transmitted or disposed by Vishvas news. This plan also applies to breaches or incidents involving personal data or posing threat to rights or freedom of individuals.

3. ABBREVIATIONS AND DEFINITIONS
Following is an explanation of various terms used within this document:

• ISMS : Information Security Management System
• ISO : Information security Officer
• Event : An event is an exception to normal operations of IT systems, infrastructure or services. Not all events become incidents.
• Security Event : A security event is a change in the everyday operations of a network or information technology service indicating that a security policy may have been violated or a security safeguard may have failed.
• Vishvas news Incident : An information security incident is a suspected, attempted, successful, or imminent threat of unauthorized access, use, disclosure, breach, modification, or destruction of information; interference with information technology operations; or significant violation of any information security related policy.
• Security Breach : A security breach is any incident that results in unauthorized access of data, applications, services, networks and/or devices by bypassing their underlying security mechanisms. A security breach may be intentional or unintentional.
• Data Breach : A data breach is a security incident in which sensitive, protected or confidential data is copied, transmitted, viewed, stolen or used by an individual unauthorized to do so. A data breach may be intentional or unintentional.
• Personal Data Breach : A data breach involving personal data or personally identifiable information of any living person or individual. Personal data breach is a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data transmitted, stored or otherwise processed.
• IRT : Incident Response Team (Comprises of stakeholders from various Functions or Teams such as IT, Admin, HR and may also include ISO)

4. RESPONSIBILITIES:

• The responsibility of executing this plan lies with Incident Response Team (IRT).
• It is the responsibility of the person reporting the incident, to provide precise information to IRT during an incident.
• iSO is responsible to ensure that the personal data breaches involving personal data or personally identifiable information (PII) are adequately and timely identified, contained, responded and resolved. ISO is responsible for necessary reporting and communication internally and externally about the personal data breaches as per the Breach Notification requirements.

5. PROCESS:

5.1 INCIDENT RESPONSE TEAM:

• For all information assets in development or undergoing significant changes, an information security risk assessment during the project planning phase should be performed to identify appropriate activities to be included during the project execution such as security requirement analysis, security testing, etc.
• The Incident Response Team is established to provide a quick, effective and orderly response to computer related incidents such as virus infections, hacker attempts and break-ins, improper disclosure of confidential information to others, system service interruptions, breach of personal information, and other events with serious information security implications.
• The Incident Response Team shall prevent a serious loss of profits, client confidence or information assets by providing an immediate, effective and skillful response to any unexpected event involving computer information systems, networks or databases.
• The Incident Response Team is authorized to take appropriate steps deemed necessary to contain, mitigate or resolve a computer security incident.
• The Incident Response Team is responsible for investigating suspected intrusion attempts or other security incidents in a timely, cost-effective manner and reporting findings to management and the appropriate authorities as necessary.
• The Incident Response Team shall consist of Stakeholders or Representatives from –

• IT Team
• Admin Team
• Human Resource
• ISO

5.2 TYPES OF INCIDENTS:

• There are many types of information security incidents that may require IRT activation.

• Breach of confidential information
• Denial of services / Distributed denial of service
• Excessive port scan
• Firewall breach
• Ransomware attack
• Server Down
• Application breaches
• Hacker’s access to Platform or Information Systems
• Unavailability of Platform or Applications
• Corruption or Deletion of Database
• Breach of Access on Production or Development or Testing environment etc.

• Below are few types of personal data related breaches or incidents that may require IRT activation involving DPO.

• Breach of personal data or PII,
• Personal Data access by an unauthorized third party,
• Deliberate or accidental action (or inaction) by a joint controller or processor,
• Sending personal data to an incorrect recipient,
• Computing devices containing personal data being lost or stolen,
• Alteration of personal data without permission,
• Non-functioning or failure of consent management processes,
• Accidental change or deletion of personal data,
• Loss of availability of personal data.
• Non fulfilment of Data Subject rights or requests including delays in fulfilment.

5.3 CLASSIFICATION / IDENTIFICATION OF POTENTIAL INCIDENT:

• All reports of potential incidents shall be classified as a high / medium / low risk to facilitate the actions to implement

• Criticality: High
  Definition: Incidents that have a monumental impact on the firm’s business or service to clients. Incidents involving personal data should be classified as Critical, irrespective of their nature or impact.
  Example: Unauthorized system access, personal data breach.

• Criticality: Medium
  Definition: Incidents that has a significant or has the potential to have a monumental impact on the firm’s business or service to its clients. 
  Example: Password cracking attempt.

• Criticality: Low
  Definitions: Incidents that has the potential to have a significant or monumental impact on the firm’s business or service to its clients.
  Example: Firewall scanning.

6. RESPONSE:

• The different phases of a security incident response plan at Vishvas news are as follows:
  
• Prepare
• Identify
• Contain
• Eradicate
• Recover
• Review

6.1 PREPARE:

• In preparing for security incidents and potential personal data breaches several items shall be addressed.
• Potential incidents and breaches shall be identified through appropriate risk assessments conducted. 
• Data protection impact assessment involving personal data and its lifecycle shall be conducted to identify potential risks and breach scenarios. Technical and Vishvas newsal measures to control and resolve such risks shall be identified.
• Actions to address potential incidents and breaches (technical and Vishvas newsal measures) shall be identified and defined including the responsibilities.
• End users including the stakeholders involved in implementing the processes shall be trained at an appropriate level.
• Login banner and warning messages shall be posted.
• Contact information as applicable shall be prepared and shall be made available for:

• personnel that might assist in handling an incident,
• key partners who may need to be notified
• business owners to make key business decisions
• outside support analysts with security expertise

• Backups should be taken at planned intervals and tested for adequacy,
• Supplies to assist the team in the event of an incident (referred as jump-bag)

• An empty notebook (Thorough documentation should be done throughout an incident to include hand-written notes in a fresh notebook.)
• Petty cash (food, cabs, batteries as needed)

• Appropriate and timely testing of planned actions or technical and Vishvas newsal measures shall be conducted to ensure the effectiveness of the same.
• Testing plan shall be developed to identify which of the response methods and processes shall be tested,
• Testing Plan shall include details such as process, methods, success criteria, responsibilities etc. 
• Testing reports / records shall be maintained by the relevant person or member of IRT driving the testing exercise.
• Any deviation from expectations, as identified during testing, shall be addressed through corrections and corrective actions so as to ensure effectiveness of the planned actions.

6.2 IDENTIFY:

• Awareness or intimation that a security incident has occurred can originate from different sources such as technical people, end users, Third parties or even clients.
• When informed about an incident, the IRT shall effectively detect deviations from normal operations in Vishvas newsal systems and identify if those deviations represent actual security incidents.
• When a potential incident is discovered, the team should immediately collect additional evidence, decide on the type and severity of the incident, and document everything for further investigation.
• Documented information shall include – Who, What, Where, Why and How.
• Wherever needed, business owners need to be involved in many security incidents to decide what are the goals in handling a particular incident, such as immediate business recovery or forensic examination.
• Wherever it is identified or suspected that the incident involves or impacts personal data in part or wholly, DPO should be involved in the investigation process to identify the magnitude of breach and impact as well as immediate containment actions to be taken.
• Wherever the personal data is impacted or suspected to be impacted, relevant stakeholders such as Processors, Joint Controllers etc. shall be intimated as applicable. Such notifications shall be done following the Breach Notification process defined by Vishvas news.

6.3 CONTAIN:

• Planned basic actions can contain many incidents.
• Actions to be taken shall depend on the nature of the incident, as well as the direction of the business owner.
• The immediate goal shall be to contain the incident and prevent further damage from occurring. This involves:

• Short term containment — This can be as simple as isolating a network segment which is under attack or taking down production servers which have been hacked and are diverting traffic to backup servers.
  
• Long term containment — Applying temporary fixes to affected systems to allow them to be used in production, while rebuilding clean systems, preparing to bring them online in the recovery stage.

6.4 ERADICATE:

• The IRT must identify the root cause of the attack, removal of malware, code issues or threats, and plan preventive actions to avoid similar attacks in the future.
• For example:

• if a weak authentication mechanism was the entry point for the attack, it should be replaced with strong authentication; if a vulnerability was exploited, it should be immediately patched.
• If machines OS has been compromised it needs to be rebuilt using hardened machines on appropriate platforms
• Test any backups prior to restore and monitor for a new incident.
• Document all the actions.

6.5 RECOVER:

• The recovery phase’s goal is to return safely to production.
• Specific actions might depend on the nature of the incident as well as the direction of the business owner.
• Key considerations include:

• Retest the system preferably with a variety of end users.
• Consider timing of the return to production.
• Discuss customer notification and their concerns
• Discuss media handling issues
• Continue to monitor for security incidents

6.6 REVIEW:

• This phase allows Vishvas news to better handle future security incidents.
• The purpose of this phase is to complete documentation that could not be prepared during the response process and investigate the incident further, to identify its full scope, how it was contained and eradicated, what was done to recover the attacked systems, areas where the response team was effective, and areas that require improvement.

6.7 REFERENCES:

• Incident Management Procedure
• Incident Register
• Breach Notification Procedure
• Breach Notification Form

6.8 DOCUMENT REVIEW:

• This document shall be reviewed at least once in 12 months, from the date of initial release or subsequent change, for ensuring the adequacy.