Skip to content

Incident Response Plan

Authoritative document

  • Link to PDF or official URL: TBD

Ownership

Field Value
Owner Takayuki KIKUCHI
Last reviewed 2026-4-13

Purpose

This document establishes the plan for managing information security incidents and events, and offers guidance for employees or incident responders who believe they have discovered, or are responding to, a security incident.

Scope

This policy covers all information security or data privacy events or incidents.

Incident and event definitions

A security event is an observable occurrence relevant to the confidentiality, availability, integrity, or privacy of company controlled data, systems or networks. A security incident is a security event which results in loss or damage to the confidentiality, availability, integrity, or privacy of company controlled data, systems or networks.

Reporting

If a Rendering Consulting Inc employee, contractor, user, or customer becomes aware of an information security event or incident, possible incident, imminent incident, unauthorized access, policy violation, security weakness, or suspicious activity, then they shall immediately report the information using one of the following communication channels:

Reporters should act as a good witness and behave as if they are reporting a crime. Reports should include specific details about what has been observed or discovered.

Severity

The CEO shall monitor incident and event tickets and shall assign a ticket severity based on the following categories.

P2/P3 - Medium and Low Severity

Issues meeting this severity are simply suspicions or odd behaviors. They are not verified and require further investigation. There is no clear indicator that systems have tangible risk and do not require emergency response. This includes lost/stolen laptop with disk encryption, suspicious emails, outages, strange activity on a laptop, etc.

P1 - High Severity

High severity issues relate to problems where an adversary or active exploitation hasn't been proven yet, and may not have happened, but is likely to happen. This may include lost/stolen laptop without encryption, vulnerabilities with direct risk of exploitation, threats with risk or adversarial persistence on our systems (e.g., backdoors, malware), malicious access of business data (e.g., passwords, vulnerability data, payments information).

P0 - Critical Severity

Critical issues relate to actively exploited risks and involve a malicious actor or threats that put any individual at risk of physical harm. Identification of active exploitation is required to meet this severity category.

Escalation and internal reporting

The incident escalation contacts can be found below in Appendix A.

Severity Escalation Path
P0 - Critical Severity P0: immediate notification to the CEO.
P1 - High Severity The CEO must also be notified via email or Slack with a reference to the ticket number.
P2/P3 - Medium and Low Severity A support ticket must be created and assigned to the CEO for response.

Documentation

All reported security events, incidents, and response activities shall be documented and adequately protected in Github. A root cause analysis may be performed on all verified P0 security incidents. A root cause analysis report shall be documented and referenced in the incident ticket. The root cause analysis shall be reviewed by the CEO who shall determine if a post-mortem meeting will be called.

Incident response process

For critical issues, the response team will follow an iterative response process designed to investigate, contain exploitation, eradicate the threat, recover system and services, remediate vulnerabilities, and document a post-mortem report including the lessons learned from the incident.

Summary

  • Event reported
  • Triage and analysis
  • Investigation
  • Containment & neutralization (short term/triage)
  • Recovery & vulnerability remediation
  • Hardening & Detection improvements (lessons learned, long term response)

Detailed

  • The CEO will manage the incident response effort
  • If necessary, a central "War Room" will be designated, which may be a physical or virtual location (i.e Slack channel)
  • A recurring Incident Response Meeting will occur at regular intervals until the incident is resolved
  • Legal and executive staff will be informed as required

Incident response meeting agenda

  • Update Incident Ticket and timelines Document new Indicators of Compromise (IOCs)
  • Perform investigative Q&A
  • Apply emergency mitigations
  • External Reporting / Breach Reporting
  • Plan long term mitigations Document Root Cause Analysis (RCA)
  • Additional items as needed

Special considerations

Internal issues

Issues where the malicious actor is an internal employee, contractor, vendor, or partner requires sensitive handling. The incident manager shall contact the CEO directly and will not discuss with other employees. These are critical issues where follow-up must occur.

Compromised communication

Incident responders must have Slack arranged before listing themselves as part of the incident response team. If there are IT communication risks, an out of band solution will be chosen, and communicated to incident responders via cell phone.

Root account compromise

If an Azure root account or Global Administrator compromise is known or expected, refer to the playbook in Appendix D.

Additional requirements

  • Suspected and reported events and incidents shall be documented
  • Suspected incidents shall be assessed and classified as either an event or an incident
  • Incident response shall be performed according to this plan and any associated procedures.
  • All incidents shall be formally documented, and a documented root cause analysis shall be performed
  • Incident responders shall collect, store, and preserve incident-related evidence in accordance with industry guidance and best practices such as NIST SP 800-86 'Guide to Integrating Forensic Techniques into Incident Response'
  • Suspected and confirmed unauthorized access events shall be reviewed by the Incident Response Team. Breach determinations shall only be made by the CEO and Legal Counsel
  • Rendering Consulting Inc shall promptly and properly notify customers, partners, users, affected parties, and regulatory agencies of relevant incidents or breaches in accordance with Rendering Consulting Inc policies, contractual commitments, and regulatory requirements, as determined by the CEO and Legal Counsel
  • This Incident Response Plan shall be reviewed and formally tested at least annually. Results of IR plan testing activities including findings and lessons learned will be formally documented and maintained to support security, compliance and audit requirements

External communications and breach reporting

Legal and executive staff shall confer with technical teams in the event of unauthorized access to company or customer systems, networks, and/or data. Legal staff along with the CEO shall determine if breach reporting or external communications are required. Breaches shall be reported to customers, consumers, data subjects and regulators without undue delay and in accordance with all contractual commitments and applicable legislation.

No personnel may disclose information regarding incident or potential breaches to any third party or unauthorized person without the approval of legal and/or executive management.

Mitigation and remediation

Legal and executive staff shall determine any immediate or long term mitigations or remedial actions that need to be taken as a result of an incident or breach. In the event that mitigations or remedial actions are needed, executive staff shall direct personnel with respect to planning, communicating and executing those activities.

Cooperation with customers, Data Controller, and authorities

As needed and determined by legal and executive staff, the company shall cooperate with customers, Data Controllers and regulators to fulfill all of its obligations in the event of an incident or data breach.

Roles & responsibilities

Every employee and user of any Rendering Consulting Inc information resources has responsibilities toward the protection of the information assets. The table below establishes the specific responsibilities of the incident responder roles.

Response Team Members

Role Responsibility
Incident Manager The Incident Manager is the primary and ultimate decision maker during the response period. The Incident Manager is ultimately responsible for resolving the incident and formally closing incident response actions. See Appendix A for Incident Manager contact information.

These responsibilities include:

- Ensuring the right people from all functions are actively involved as appropriate
- Communicating status updates to the appropriate person or teams at regular intervals
- Resolving incidents in the immediate term
- Determining necessary follow-up actions
- Assigning follow-up activities to the appropriate people
- Promptly reporting incident details which may trigger breach reporting, in writing to the CEO
Incident Response Team (IRT) The individuals who have been engaged and are actively working on the incident. All members of the IRT will remain engaged in incident response until the incident is formally resolved, or they are formally dismissed by the Incident Manager.
Engineers (Support and Development) Qualified engineers will be placed into the on-call rotation and may act as the Incident Manager (if primary resources are not available) or a member of the IRT when engaged to respond to an incident. Engineers are responsible for understanding the technologies and components of the information systems, the security controls in place including logging, monitoring, and alerting tools, appropriate communications channels, incident response protocols, escalation procedures, and documentation requirements. When Engineers are engaged in incident response, they become members of the IRT.
Users Employees and contractors of Rendering Consulting Inc. Users are responsible for following policies, reporting problems, suspected problems, weaknesses, suspicious activity, and security incidents and events.
Customers Customers are responsible for reporting problems with their use of Rendering Consulting Inc services. Customers are responsible for verifying that reported problems are resolved.
Legal Counsel Responsible, in conjunction with the CEO and executive management, for determining if an incident presents legal or regulatory exposure as well as whether an incident shall be considered a reportable breach. Counsel shall review and approve in writing all external breach notices before they are sent to any external party.
Executive Management Responsible, in conjunction with the CEO and Legal Counsel, for determining if an incident shall be considered a reportable breach. An appropriate company officer shall review and approve in writing all external breach notices before they are sent to any external party. Rendering Consulting Inc shall seek stakeholder consensus when determining whether a breach has occurred. The Rendering Consulting Inc CEO shall make a final breach determination in the event that consensus cannot be reached.

Management commitment

Rendering Consulting Inc management has approved this policy and commits to providing the resources, tools and training needed to reasonably respond to identified security events and incidents with the potential to adversely affect the company or its customers.

Exceptions

Requests for an exception to this Policy must be submitted to and authorized by the CEO for approval. Exceptions shall be documented.

Violations & enforcements

Any known violations of this policy should be reported to the CEO. Violations of this policy may result in immediate withdrawal or suspension of system and network privileges and/or disciplinary action in accordance with company procedures up to and including termination of employment.

Appendix A — Contact information

Contacts for the Incident Response Team can be found in the Key Contacts List.

Appendix B — Incident collection form

Use the live English form: Incident collection form. Submit once per affected information system (same URL for each submission) so each response describes a single system.

Appendix D — Azure Global Administrator compromise playbook

Objective

The objective of this runbook is to provide specific guidance on how to manage Azure Global Administrator account usage. This runbook is not a substitute for an in-depth Incident Response strategy. This runbook focuses on the IR lifecycle:

  • Establish control
  • Determine impact
  • Recover as needed
  • Investigate the root cause
  • Improve

The Indicators of Compromise (IOC), initial steps (stop the bleeding), and the detailed steps needed to execute those steps are listed below.

Assumptions

  • Azure CLI configured and installed
  • Reporting process is already in place
  • Microsoft Defender for Cloud is active
  • Microsoft Sentinel or Azure Monitor is active

Indicators of Compromise

  • Activity that is abnormal for the account:
  • Creation of new Entra ID (Azure AD) users or service principals
  • Disabling of Azure Monitor or Diagnostic Settings
  • Disabling of Microsoft Defender for Cloud
  • Unusual changes to role assignments or privileged identity management (PIM) settings
  • Unexpected modifications to subscription-level policies
  • Launching of new or unexpected virtual machines or resources
  • Changes to the contacts or billing information on the account

Steps to Remediate — Establish Control

Microsoft documentation for a possible compromised account calls out the specific tasks listed below.

  1. Contact Microsoft Azure Support as soon as possible
  2. Change and rotate the Global Administrator password and register an MFA device associated with the account
  3. Rotate secrets, client credentials, and access keys for all service principals and managed identities
  4. Review sign-in logs and audit logs in Microsoft Entra ID for suspicious activity
  5. Open the runbooks for any suspicious actions identified
  6. Close incident
  7. Review the incident and understand what happened
  8. Fix the underlying issues, implement improvements, and update the runbook as needed

Further Action Items — Determine Impact

Review created resources and mutating operations. There may be items that have been created to allow access in the future. Some things to look at:

  • Entra ID cross-tenant access configurations
  • Entra ID users and service principals
  • Azure Storage accounts and containers
  • Azure Virtual Machines and scale sets
  • Azure Key Vault access policies