# How Asana uses Asana: Security incident response - The Asana Blog > Read how the Asana Security team uses Asana to run incident response, written by Asana's Head of Security, Sean Cassidy. Source: https://asana.com/inside-asana/engineering-security-incident-response ## How Asana uses Asana: Security incident response Typically, security teams coordinate security incident response with a few tools, such as text chat, video chat, collaborative documents, and so on. [Asana’s Security team](https://blog.asana.com/2020/03/meet-security-engineering-team/), unsurprisingly, uses Asana for most everything, including for incident response! We developed a Security Incident Response Project [Template](https://asana.com/guide/team/advanced/create-use-asana-templates)* to manage and track this work end-to-end with our global team. Read on for six ways that using this template has helped us collaborate better to run more effective security incident response. ### 1. Knowing who is doing what, by when Nearly everyone who has been part of a security incident has had the experience of not knowing the status of either a specific task, the entire incident, or even where to start. We wanted to make sure that was not the case here. We set up our [project](https://asana.com/guide/help/projects/basics#gl-create) template to make incident roles explicit by having a section at the top of our project called Roles. This section defines who is responsible for which roles in our incident response process. If anyone is unsure of who is responsible, or who is working with us from cross-functional teams like Legal or Communications, they can use this section of the project to find out. It’s also handy for long-running incidents when people need to rotate off of the incident. _Note: All project images in this post are examples. They are not actual projects and tasks used by our Security team._ Even though these roles are Asana tasks, we’re using them as reference tasks in this case and don’t complete them until the incident is completely done. At Asana, we often use tasks this way to document responsibilities. We also keep track of what we need to do with an Emergency Mitigations section, which has assignees and due dates. It’s clear what has and has not been done. Any member of the incident response team is allowed to submit proposed migitations. For complex incidents, we often use [automation](https://asana.com/product/automation) to assign newly proposed mitigations to the Incident Response Coordinator for approval. ### 2. Asking questions without interruption One of the biggest sources of frustration in any complex incident is when stakeholders ask questions while the rest of the team is trying to remediate as soon as possible. These questions can feel like interruptions, but many times, the questions they ask are important! To mitigate these interruptions, we have a section in our project template for Investigative Q&A. Anyone from the incident response coordinator, to stakeholders, to team members, etc. can add questions as tasks in this section. The questions are there waiting for us to answer when we can, and sometimes, we mark questions as [dependent](https://asana.com/guide/help/tasks/dependencies) on other questions or remediation work. This makes it clear what steps we need to take to answer the question and when the question will be answered. ### 3. Tracking approvals Sometimes in incident response, we need to make tough calls, like disabling key functionality, notifying affected customers, or spending a significant amount of money on something. Other times, we only need to make sure the message we’re sending is accurate. We track these decisions through [Asana’s approval tasks](https://asana.com/guide/help/premium/approvals). One common pattern we use is having a parent task with a message or decision with subtasks for approvals. Key decision makers can approve, request changes, or reject approval tasks. If someone rejects or requests changes, we revisit the proposal and try to adapt it to best fit the situation. ### 4. Clear status updates For significant incidents, there are usually many people who care about staying informed on progress. We use [status updates](https://asana.com/guide/videos/status-updates) in our project to keep all of our stakeholders in the know about our security incident so they do not have to follow along with the minutia within the project. If stakeholders have questions, they can either post a comment on the status update, or ask them in the Q&A section of the project. By using status updates, we also have an easy way to see the history of an incident. We can use that information in a [five whys process](https://en.wikipedia.org/wiki/Five_whys) reflecting on something that may have gone wrong, and for auditing purposes. We hold ourselves accountable to posting periodic status updates for incidents, and even have internal KRs (key results) set to keep us consistent in posting these updates. ### 5. Assigning action items One of the most commonly missed parts of incident response is the follow-up action items. Once an incident is closed, responders quickly lose context if action items are not addressed. After the incident is over, it’s important to keep track of how you ensure that you improve your security posture. If you don’t, you risk having the same security incident again and again. We use [multi-homing](https://asana.com/guide/help/tasks/fields#gl-multi-home) to keep track of important action items. [Multi-homing](https://asana.com/guide/videos/multi-home) means that the same task is stored in more than one project. When the task is edited or changes in any way, it is automatically reflected in every project that task is in. Each remediation item goes in a team’s backlog. If the same remediation item shows up in multiple incident projects, then we know we need to fix it ASAP! Any task that is added to the Long-term Mitigations section is automatically multi-homed into another project called Security Incident Action Items. A best practice is to routinely monitor this backlog to prioritize high impact action items out of security incidents. We use a custom Asana bot that routinely bumps action items for prioritization and timely response. ### 6. Running multiple incidents at once We use a primary security incident [portfolio](https://asana.com/product/portfolios) that stores all of our security incident projects. This way, we can keep track of multiple incidents at once. We label these with a [custom field](https://blog.asana.com/2019/07/new-custom-field-updates/) for Severity to sort these projects so we can make sure we pay the most attention to SEV0 incidents. We make regular portfolio status updates about our security incident metrics and for high level updates and insights. ### Better collaboration to improve security incident response Using Asana to manage security incident response has made a significant improvement in how we collaborate by getting us into one centralized place and out of chat, video calls, and collaborative documents. It enables us to work seamlessly with our teammates around the globe to not only to understand who is doing what by when, but also to keep our stakeholders up-to-date. What do you think? How do you coordinate security incident response at your company? _*The original design of this project template was deeply inspired by_[Ryan McGeehan’s breach response agenda](https://medium.com/starting-up-security/security-breach-101-b0f7897c027c)_blog post. Thanks, Ryan! Our roles were inspired by_[PagerDuty’s incident commander framework](https://response.pagerduty.com/training/incident_commander/)_._ - [キャッシュをそのままにして、ブラウザーエージェントのコストを 76 分の 1 に削減し、5 倍高速化した方法](/ja/inside-asana/cut-browsers-agent-cost) エンジニアリング 人工知能 (AI) #### StackAI の CTO コードの調査から結果の測定まで、Codex で GPT-6 Astra を使用した 4 つのモデルに関する調査調査の目的Asana は、StackAI を通じてエージェントのワークフローのオートメーションをプラットフォームに導入しています。Asana の規模では、小さな非効率性が積み重なっていきます。 私たちの目標は、回答の質を落とすことなく、ブラウザーエ ... - [管理者コンソール内のマイクロフレームワーク](/ja/inside-asana/microframeworks-admin-console) エンジニアリング すべての Asana 展開には管理者コンソールがあります。 IT 管理者は、パスワードの要件、役割と権限、Dropbox からファイルを添付できるかどうか、デフォルトで新規プロジェクトを閲覧できるユーザーなどを設定し、会社における Asana の使用方法を構成します。Asana が成長するにつれて、管理者コンソールには長年にわたるカスタムロジックや一時的な ... - [仕様主導の開発: メリットと 3 か月間で学んだこと](/ja/inside-asana/spec-driven-development) エンジニアリング #### スタッフソフトウェアエンジニア 3 か月が経過した時点で、追加された構造が役に立つ場面と邪魔になる場面がより明確になりました。あるエンジニアがデータ移行の準備を進める中で、作業計画に仕様駆動型開発 (SDD) を採用することにしました。 SDD は、早期にギャップを特定し、アプローチのレビューを容易にし、エージェントに明確な方向性を示すことを目的としていました。 その結果生まれた計画は詳 ... - [Enzyme からの移行は 2 週間で完了しました。本来は 5 年かかるはずでした。](/ja/inside-asana/migrating-off-enzyme-2-weeks) エンジニアリング 最近、AI を使って、数年にわたるエンジニアリング作業を 1 スプリント程度で完了させました。 その方法と、それがなぜ可能性についての考え方を変えたのかをご紹介します。5 年間の問題2022年、Asana はフロントエンドのテストスイートを、古くなったテストライブラリの Enzyme から React Testing Library (RTL) に移行する ... - [How Asana uses Asana: Security incident response](/ja/inside-asana/engineering-security-incident-response) エンジニアリング Typically, security teams coordinate security incident response with a few tools, such as text chat, video chat, collaborative documents, and so on. Asana’s Security team, unsurpr ... - [エンジニアリング](/inside-asana/engineering-spotlight)