Initially, we were using Slack for small automations, such as creating pipelines or shutting down servers. For example, I could shut down one of our Angular services on one of our servers through a slash command in Slack. To automate this process, we migrated everything from Slack to Torq. Currently, we are in the migration phase, with most of it completed, though some portions are still pending. We use Torq for identity management. For identity purposes, we create user accounts and have a workflow that creates a user account, adds that user into Slack, and grants Git access. This workflow handles user additions, deletions, and modifications related to identity, and it is working very well. We are not using Torq extensively for security purposes, as we have limited use cases for security. However, we are using it for day-to-day activities and general automations, which are also working well.
My usual use cases for Torq involved more than 70 customers. We were an MSSP back then, and there were all sizes of customers with different industry verticals. Since our company was a Microsoft shop, we had a lot of Microsoft solutions integrating with Torq. We had an in-house Security Operations Center that worked 24/7. Torq was utilized in an MSSP model wherein we had different client workspaces, a pro-arc, and a parent workspace. From alert ingestion, incident investigation, triage investigation, to response, we were using Torq. We also built a lot of workflows within Torq that handled malware analysis, email phishing analysis, and identity access management analysis, such as alerts from identity and access management. Additionally, we developed a vulnerability prioritization solution for our clients, which went to market, and many clients appreciated this solution as it provided significant insights into vulnerabilities relevant for them, driven by threat intelligence. My experience with Torq's Identiq AI regarding increasing alert handling capacity for our SecOps staff involves using Socrates, the AI orchestrator in Torq. Unfortunately, when I was working with Torq, I did not get hands-on experience with their Identiq AI capabilities because it was not available at that time. However, I utilized Socrates orchestrators within the platform that did help reduce some of the workload for our SOC analysts, but it was very premature back then. They later introduced a lot of features after we started implementing, which really helped. It is effective in handling alerts as long as you provide summarized data; otherwise, it could blow out of context and hallucinate. When I used Torq, it was indeed in the early stages of AI capabilities. Only a few customers were allowed to use it, and we were among them. It functioned well as long as we summarized the data properly. If you input garbage, you would get garbage out. Thus, we had to do significant fine-tuning regarding what data context we provided to the AI orchestrator to get meaningful results from a case or alert. There are features allowing us to dump plain JSON logs into case management, but that would not help much because the data context would be too large. They also have a certain token size limit, meaning we would only get meaningful results if we stayed within that limit. Hence, context is crucial, and they can improve on developing tools to enrich case data, providing meaningful context to the AI orchestrator. In terms of Torq's unified platform approach to AI SOC automation and case management compared to managing multiple point solutions across my security stack, I find it case-centric. They have many triggers that execute workflows based on specific changes in the cases. Each time there is a change an analyst makes in case management, it triggers a workflow. It is a case-centric platform, and when discussing a unified view, it is essentially about integrating various security solutions using API and some authentication, bringing in the data and allowing the workflows to do the work. Now, every time we need to use Torq, whether for reporting or workflow execution, we have to go through a case; otherwise, it is more isolated, requiring some interactive tasks to manage the inputs and execute the workflow. I have used Torq to automate triage, investigation, and remediation actions across multiple attack surfaces, including endpoint, identity, cloud, and IT. They provide good connector actions for various remediations like isolating or quarantining devices or blocking IPs. As long as the third-party API supports those actions, Torq can effectively deliver these connector actions. In cases where Torq lacks connector actions, there are HTTP steps and actions we can configure to hit the API endpoint and perform response actions. Torq is deployed only in the cloud in our organization, whereas Swimlane offers flexibility for customers to choose between on-premises or cloud deployments. We are using Azure as our specific cloud platform.
Torq is primarily used for security operations, mainly for the SOC team. I develop use cases based on requirements from what the SOC team does in everyday operations. Based on those requirements, I implement security use cases and automations. For example, when a new user is created, there is a simple workflow where you provide a username, start the workflow, and it completes execution, creating the user everywhere without issues. We have a lot of use cases implemented and are actively using them. Torq automates triage, investigation, and remediation actions across multiple attack surfaces. Currently, we are using it for SOC operations only, but it satisfies everything we need.
I use Torq as my case management and alert system. Working as a SOC analyst, the first thing I do every morning is get into Torq, review all the open cases and incidents, understand their severity, investigate them, and close them if they are legitimate. I also investigate whether there is anything malicious. I use Torq daily. We build workflows inside Torq—automations that can automate every action that we do manually. For example, we send Slack messages to users who we think shared corporate data, or investigate specific machines where we suspect there is some sort of SQL injection. We can automate every type of security-related incident through the workflows in Torq.
Information Technology Specialist at a media company with 201-500 employees
Real User
Top 10
Feb 1, 2026
Torq markets itself as a security tool, and we do use them for security, but not in the traditional sense they market. Our security implementation uses them for internal tools that require multi-step processes of approvals, and it's easier to execute via workflow. Our biggest use case for Torq is onboarding and offboarding, which previously involved a very convoluted internal process. We made it automatic and secure by transforming these multi-step internal processes into rigid workflows, which provided security benefits. Torq provided an excellent introduction to no-code automation for me personally. Before signing with them, we evaluated Torq and other similar companies. Torq gave us the best of both worlds where it's easy to get into, but it also provides enough options. Some applications offer way more flexibility, while others are easier to use, but Torq struck a good balance for us with its visual branching tree workflow of no-code automation. This was a great way for me to enter the field, and even now, after building very long workflows, it remains easy to jump back into and understand what's happening, and I can edit it on the fly. Other than using API keys in workflows that sometimes need to be rotated, I cannot identify any needed updates. If you use an API key, it might expire, and then you need to enter the workflow or access the secrets in Torq to add a new one. For any team, whether security or IT, looking to automate and wanting to do it fairly easily without using scripts or hosting something, no-code automation in general is something I would advise. Torq would obviously be my first recommendation because I personally use them. If I am already speaking with somebody who implemented it, I would probably help them build it in a smarter way than we did because even in no-code automation, you can build things that eventually need to be refactored and rebuilt in a better way, which is harder to do than leaving them as is. I would probably help a different customer of Torq who is just starting out by giving them best practices, such as splitting up your workflows, using nested workflows, and trying to immediately incorporate AI. If you build a rigid workflow and then add AI, you will not be satisfied with the result. These are best practices for the application that I would mostly give. Our entire team personally works with Torq, which is four people. Our surrounding teams currently do not use Torq, but approximately six months ago, we created another workspace that we wanted to incorporate our development team into because we see the value in giving developers the option to build their own workflows for simple tasks. I started trying to help some of them adopt it and guide them through how to use Torq. For something as small as a developer who wants to get a daily alert about their tickets with a couple of parameters, it is just easier to do it via Torq than doing it via Jira.
CyberSecurity Engineer at a real estate/law firm with 10,001+ employees
Real User
Top 10
Jan 14, 2026
My role is Cyber Security Engineer, and we use Torq for our case management platform, automating some of our phishing workflows to automate the containment of account takeover users, which are probably our biggest use cases. I have used Torq to automate triage, investigation, and remediation across multiple attack surfaces, including endpoint, identity, cloud, IT, and others.
Senior Consultant at a university with 10,001+ employees
MSP
Top 20
Oct 22, 2025
I used Torq for conducting one of the proof of evaluations for a vendor we are connected with. I am currently working with Omnisoc, which provides SOC services for twenty-three other higher education institutions in the US. As part of vendor evaluations, we used Torq to differentiate between the manual workflow we had and the security automation provided with the Torq AI automation capability. We have used it to differentiate between our manual workflow and the capability it brought us in creating playbooks for many of the detections we have had. In that scenario, although we are an education organization which deals with education-related logs, we should not have much exposure to the data held at different members. From our research and testing with the tool, we realized there have to be modifications and changes to train the LLM on the back end. It was able to capture data but was unable to differentiate between the agent hostname we are using and the hostname that resides on the back end of the Internet. It was unable to do that sort of classification. We concluded this tool would be more suitable for initial ticket management rather than security automation. With the use of AI prompts, we were able to start with preparation of the tool through the last chain of niche, which is the remediation part. With the help of prompts, we were able to perform everything present on instant response plan.
Torq is the enterprise AI SOC solution that effectively combines adaptive insights and automation to handle critical threats efficiently. It manages threat lifecycles, swiftly moving from triage to response, ensuring effective risk management.Torq is designed to streamline security operations by aggregating telemetry across your security stack. It investigates significant risks and manages threats from triage to containment and remediation. This AI-driven tool enhances the capabilities of...
Initially, we were using Slack for small automations, such as creating pipelines or shutting down servers. For example, I could shut down one of our Angular services on one of our servers through a slash command in Slack. To automate this process, we migrated everything from Slack to Torq. Currently, we are in the migration phase, with most of it completed, though some portions are still pending. We use Torq for identity management. For identity purposes, we create user accounts and have a workflow that creates a user account, adds that user into Slack, and grants Git access. This workflow handles user additions, deletions, and modifications related to identity, and it is working very well. We are not using Torq extensively for security purposes, as we have limited use cases for security. However, we are using it for day-to-day activities and general automations, which are also working well.
My usual use cases for Torq involved more than 70 customers. We were an MSSP back then, and there were all sizes of customers with different industry verticals. Since our company was a Microsoft shop, we had a lot of Microsoft solutions integrating with Torq. We had an in-house Security Operations Center that worked 24/7. Torq was utilized in an MSSP model wherein we had different client workspaces, a pro-arc, and a parent workspace. From alert ingestion, incident investigation, triage investigation, to response, we were using Torq. We also built a lot of workflows within Torq that handled malware analysis, email phishing analysis, and identity access management analysis, such as alerts from identity and access management. Additionally, we developed a vulnerability prioritization solution for our clients, which went to market, and many clients appreciated this solution as it provided significant insights into vulnerabilities relevant for them, driven by threat intelligence. My experience with Torq's Identiq AI regarding increasing alert handling capacity for our SecOps staff involves using Socrates, the AI orchestrator in Torq. Unfortunately, when I was working with Torq, I did not get hands-on experience with their Identiq AI capabilities because it was not available at that time. However, I utilized Socrates orchestrators within the platform that did help reduce some of the workload for our SOC analysts, but it was very premature back then. They later introduced a lot of features after we started implementing, which really helped. It is effective in handling alerts as long as you provide summarized data; otherwise, it could blow out of context and hallucinate. When I used Torq, it was indeed in the early stages of AI capabilities. Only a few customers were allowed to use it, and we were among them. It functioned well as long as we summarized the data properly. If you input garbage, you would get garbage out. Thus, we had to do significant fine-tuning regarding what data context we provided to the AI orchestrator to get meaningful results from a case or alert. There are features allowing us to dump plain JSON logs into case management, but that would not help much because the data context would be too large. They also have a certain token size limit, meaning we would only get meaningful results if we stayed within that limit. Hence, context is crucial, and they can improve on developing tools to enrich case data, providing meaningful context to the AI orchestrator. In terms of Torq's unified platform approach to AI SOC automation and case management compared to managing multiple point solutions across my security stack, I find it case-centric. They have many triggers that execute workflows based on specific changes in the cases. Each time there is a change an analyst makes in case management, it triggers a workflow. It is a case-centric platform, and when discussing a unified view, it is essentially about integrating various security solutions using API and some authentication, bringing in the data and allowing the workflows to do the work. Now, every time we need to use Torq, whether for reporting or workflow execution, we have to go through a case; otherwise, it is more isolated, requiring some interactive tasks to manage the inputs and execute the workflow. I have used Torq to automate triage, investigation, and remediation actions across multiple attack surfaces, including endpoint, identity, cloud, and IT. They provide good connector actions for various remediations like isolating or quarantining devices or blocking IPs. As long as the third-party API supports those actions, Torq can effectively deliver these connector actions. In cases where Torq lacks connector actions, there are HTTP steps and actions we can configure to hit the API endpoint and perform response actions. Torq is deployed only in the cloud in our organization, whereas Swimlane offers flexibility for customers to choose between on-premises or cloud deployments. We are using Azure as our specific cloud platform.
Torq is primarily used for security operations, mainly for the SOC team. I develop use cases based on requirements from what the SOC team does in everyday operations. Based on those requirements, I implement security use cases and automations. For example, when a new user is created, there is a simple workflow where you provide a username, start the workflow, and it completes execution, creating the user everywhere without issues. We have a lot of use cases implemented and are actively using them. Torq automates triage, investigation, and remediation actions across multiple attack surfaces. Currently, we are using it for SOC operations only, but it satisfies everything we need.
I use Torq as my case management and alert system. Working as a SOC analyst, the first thing I do every morning is get into Torq, review all the open cases and incidents, understand their severity, investigate them, and close them if they are legitimate. I also investigate whether there is anything malicious. I use Torq daily. We build workflows inside Torq—automations that can automate every action that we do manually. For example, we send Slack messages to users who we think shared corporate data, or investigate specific machines where we suspect there is some sort of SQL injection. We can automate every type of security-related incident through the workflows in Torq.
Torq markets itself as a security tool, and we do use them for security, but not in the traditional sense they market. Our security implementation uses them for internal tools that require multi-step processes of approvals, and it's easier to execute via workflow. Our biggest use case for Torq is onboarding and offboarding, which previously involved a very convoluted internal process. We made it automatic and secure by transforming these multi-step internal processes into rigid workflows, which provided security benefits. Torq provided an excellent introduction to no-code automation for me personally. Before signing with them, we evaluated Torq and other similar companies. Torq gave us the best of both worlds where it's easy to get into, but it also provides enough options. Some applications offer way more flexibility, while others are easier to use, but Torq struck a good balance for us with its visual branching tree workflow of no-code automation. This was a great way for me to enter the field, and even now, after building very long workflows, it remains easy to jump back into and understand what's happening, and I can edit it on the fly. Other than using API keys in workflows that sometimes need to be rotated, I cannot identify any needed updates. If you use an API key, it might expire, and then you need to enter the workflow or access the secrets in Torq to add a new one. For any team, whether security or IT, looking to automate and wanting to do it fairly easily without using scripts or hosting something, no-code automation in general is something I would advise. Torq would obviously be my first recommendation because I personally use them. If I am already speaking with somebody who implemented it, I would probably help them build it in a smarter way than we did because even in no-code automation, you can build things that eventually need to be refactored and rebuilt in a better way, which is harder to do than leaving them as is. I would probably help a different customer of Torq who is just starting out by giving them best practices, such as splitting up your workflows, using nested workflows, and trying to immediately incorporate AI. If you build a rigid workflow and then add AI, you will not be satisfied with the result. These are best practices for the application that I would mostly give. Our entire team personally works with Torq, which is four people. Our surrounding teams currently do not use Torq, but approximately six months ago, we created another workspace that we wanted to incorporate our development team into because we see the value in giving developers the option to build their own workflows for simple tasks. I started trying to help some of them adopt it and guide them through how to use Torq. For something as small as a developer who wants to get a daily alert about their tickets with a couple of parameters, it is just easier to do it via Torq than doing it via Jira.
My role is Cyber Security Engineer, and we use Torq for our case management platform, automating some of our phishing workflows to automate the containment of account takeover users, which are probably our biggest use cases. I have used Torq to automate triage, investigation, and remediation across multiple attack surfaces, including endpoint, identity, cloud, IT, and others.
I used Torq for conducting one of the proof of evaluations for a vendor we are connected with. I am currently working with Omnisoc, which provides SOC services for twenty-three other higher education institutions in the US. As part of vendor evaluations, we used Torq to differentiate between the manual workflow we had and the security automation provided with the Torq AI automation capability. We have used it to differentiate between our manual workflow and the capability it brought us in creating playbooks for many of the detections we have had. In that scenario, although we are an education organization which deals with education-related logs, we should not have much exposure to the data held at different members. From our research and testing with the tool, we realized there have to be modifications and changes to train the LLM on the back end. It was able to capture data but was unable to differentiate between the agent hostname we are using and the hostname that resides on the back end of the Internet. It was unable to do that sort of classification. We concluded this tool would be more suitable for initial ticket management rather than security automation. With the use of AI prompts, we were able to start with preparation of the tool through the last chain of niche, which is the remediation part. With the help of prompts, we were able to perform everything present on instant response plan.