Information Security Incident Management Policy And Procedure¶

Information security incident MANAGEMENT POLICY and Procedure

Version history¶

Version Number	Date	Description	Created By	Approved By
0.1	23/Apr/2024	Initial Copy	[Name] [Name]
0.2	18/Jun/2024	Approved	[Name] [Name]	[Name]
0.3	28/Aug/2026	Knowledge kernel, AI/agents, control alignment	Knowledge steward	[Name]

Purpose¶

Defines rules for managing information security incidents.
Includes reporting, categorization, resolution, causal analysis, and planning corrective actions.
Ensures a prompt and effective response to potential harm to the Company.

Scope¶

Applies to all information security incidents within tecciance.
Applicable to all employees and related departments encountering any information security incident.

Roles and Responsibilities¶

Following are the roles and responsibilities across hierarchy at tecciance to ensure effective implementation and management of Information Security Incident Management policy:

Primary ownership with the Information Security Team
All employees responsible for reporting events.
Incident handling team responsible for responding.

Policy¶

Incident/ IT Incident¶

An incident / IT incident can be defined as an unplanned interruption of normal service operation. Examples of incidents include but not limited to: user unable to logon to system, email service issue, laptop crash, file sharing issue, technical issues, theft, phishing emails, etc.

Incident Management Policy¶

tecciance shall have a formal Information Security Incident Management policy and procedure which shall define the process for Incident Preparation, Identification & Reporting, Triaging and Analysis, Severity and Impact, Containment, Escalation, Communication, Resolution and Lessons learned from Incidents.
The policy and procedure shall also identify Roles and responsibilities and define the incident categories and the forms of communication channels through which such incident can be reported.
Employees and contractors shall be made aware of their responsibility to report any information security events / incidents and the requirements of the information security procedure.
Employees and contractors shall be informed of the disciplinary actions that would be invoked in the event of any information security breach.
Situations to be considered for information security event reporting shall include, but not limited to,
Ineffective security control
Breach of information integrity, confidentiality, privacy, security, or availability expectations
Human errors
Non-compliances with policies or guidelines
Breaches of physical security arrangements
Uncontrolled system changes
Malfunctions of software or hardware
Access violations
Virus infection, phishing, social engineering attacks, data breaches and hacking attacks.
tecciance shall notify and report any information security events / incidents to customers as defined within the contractual agreements.
Incident tracker shall be shared to Steering Committee by IS Team on a periodical basis during the MRM.
Reported and suspected information security events shall be assessed to determine if they are to be classified as information security incidents.
Results of the assessment and decision shall be recorded in detail for the purpose of future reference and verification.
Learning from incidents shall be recorded along with analysis and remedial actions and the information gained from evaluation of information security incidents shall be used to identify recurring or high impact incidents.
Learning from incidents shall be used to identify and deploy appropriate and more stringent security controls, policies, and procedures.
Frequently occurring incidents shall be monitored and shall be discussed in the Steering Committee meetings to review the mitigating solutions.
Where possible and with due care to confidentiality aspects, learnings from incidents shall be used in information security training and awareness programs.
Procedure for collection of evidence shall consider requirements for proper of chain of custody, safety of evidence and personnel, roles and responsibilities of personnel authorized to handle evidence, competency of personnel and documentation of evidence.
In case tecciance is using any services from a third-party vendor, appropriate security incident management process shall be defined and included as part of the contractual agreement.

Incident Management Procedure¶

An incident is defined as any event/activity/situation against the information security policy or supporting practices.
Information Security incidents may be defined as the occurrence of any exceptional situation that could compromise the Confidentiality, Integrity, Security, Privacy or Availability of tecciance’s information assets, system, devices, reputation, and personnel which in turn may lead to an interruption of normal service operation.
An incident can be both accidental and deliberate. It can be internal or external. It can be an event that may require a review of organizational policy/process or an existing control.

The scope of reporting includes both an event and a weakness. The list below provides examples of security incidents but not limited to:

Disclosure of information to unauthorized people through deliberate or careless action.
Internal or external attempts (either failed or successful) to gain unauthorized access to the tecciance’s network (e.g., Hacking, Network intrusion, Spam, or malware).
Theft, destruction, defacement, or misuse of tecciance’s information asset
Uncontrolled changes to system hardware, firmware, or software characteristics
Failure to abide / involved in attempting and violating tecciance’s Information Security Policies
Non-availability of tecciance’s cloud product through Denial of service (DoS) or unauthorized disruption to tecciance’s Production / Corporate network.
Few other examples include end-user events such as (but not limited to):
Security Controls not operational such as doors not getting closed, anti-virus signatures showing old dates of updates, firewall allowing traffic despite policy controls etc.
Desktop/laptop – malicious activity.
Access control systems – non-operational or delayed response.
Suspected malware
Information leakage by insider
A weakness in the system can also be considered a situation for reporting, and therefore can be reported by any personnel. (A weakness if not addressed may result in a Security incident to take place.) A weakness can be a part of the management system, where there are no specific policies/procedure defined, and can therefore pose a threat.
An incident can relate to any information/related infrastructure which in the opinion of the incident reporter can compromise the confidentiality, Integrity, security, privacy and/or availability of tecciance operations.

Guidelines for Incident Reporting¶

Management responsibilities and procedures should be established to ensure a quick, effective, and orderly response to Security Incidents and identified weakness.
The objectives for Security Incident management should be agreed upon with management, and it should be ensured that those responsible for Security Incident management understand the organization’s priorities for handling Security Incidents.
Personnel and contractors using the organization’s information systems and services are required to note and report any observed or suspected Security Weakness in systems or services.
Security Events should be assessed, and it should be classified with respect to the Severity Rating specified.
Knowledge gained from analyzing and resolving Security Incidents should be used to reduce the likelihood or impact of future incidents.
Procedures should be defined and applied for the identification, collection, acquisition, and preservation of information, which can serve as evidence.
In the event a Security Incident, Data Controllers, government bodies and other necessary parties should be notified in a reasonable timeframe, and in compliance with regulatory and other applicable requirements and guidance.

Response to Information Security Incident¶

Owners are assigned to handle and manage Incidents.
Evidence/Logs are collected for Incidents.
All response activities are recorded for future analysis and
Weaknesses Identified as the cause of the incident are worked on and dealt with to avoid pertaining incidents.
Incident Register details are shared with Management periodically.

References¶

tecciance Incident Tracker

Terms & Definitions¶

Explanation of various terms used within this document: Information Security Team
Information Security: Protection of confidentiality, integrity, and availability of information and information assets.
Event: An exception to normal operation.
Incident: An event indicating harm or high potential harm to the company. Security Event: A change indicating a possible violation of security policy.
Information Security Incident: Suspected, attempted, successful, or imminent threat to information security.
Security Breach: Unauthorized access resulting in data breach. Data Breach: Unauthorized access to sensitive data.
Personal Data Breach: Unauthorized access involving personal data. RCCA: Root Cause Corrective Action.
Incident Handling Team: Team handling or resolving Incidents.

Artificial intelligence, software agents, and organizational knowledge¶

This section is added in version 0.3 so the policy applies equally to employees and to software agents, and so reusable knowledge stays provenanced.

Software agents, bots, service accounts, CI jobs, and coding assistants are identities. They are in scope of this policy wherever people are.

Every retrieve or use of organizational knowledge or classified data requires a verified identity, a stated purpose, and a classification ceiling. Missing purpose is deny.

AI may extract, draft, rank, or propose. AI shall not approve access, classify or reclassify information, set reuse rights, waive a control, merge to a protected branch, or treat search ranking as truth.

Approved reusable knowledge is a governed claim with source, owner, lifecycle, applicability, and limitations. Raw chat, tickets, and scanner output are not approved knowledge.

Embeddings, summaries, caches, and compiled agent skills are derivatives. Withdrawal, reclassification, or destruction of a source shall propagate to derivatives.

Secrets, credentials, production data dumps, and Restricted (including client/PHI) material shall not be pasted into public generative-AI services or stored in vector indexes unless an authorized path and agreement exist.

HIPAA-regulated PHI is out of default scope. Enable the HIPAA pack and a business-associate path before any PHI is processed by agents or knowledge indexes.

Change to a must procedure (including knowledge used by agents) is a change under the Change / Release procedure and SOC 2 CC8.1. Agents cannot approve that change.

Suspected leakage of data into an unapproved model, agent, or public copilot is an information-security incident.