What needs improvement with Torq?

What has not worked as well as I hoped with Torq is related to product data management and storing data, although it still provides faster response and saves time. I think Torq is a good product as it is.

There are some bugs in Torq, of course. They can be present in data transformation, some UI debugging, and other areas that can be improved. There are some ideas, and Torq always takes them into consideration. Unfortunately, they are currently focused too much on AI and how the tool is evolving. I can understand because this is how they can keep their head above the water and ahead of all the other tools. This is how they can be this disruptive and interesting for companies. However, it is also important to have some good bases, some solid baselines. There are some issues and bugs that I think need to be fixed, but they are currently not focused on it. The tool is working overall. It is doing what we need. No tool can be perfect, and there is room for improvement, but Torq is already quite far advanced compared to others in the market. One of the things that I think would be the most interesting for Torq is the ability, when you are debugging, when you have a crash in a playbook, to rerun the playbook from the step that has crashed. This is not implemented, and it is painful to relaunch a playbook manually and do everything when you have actions inside a playbook that have impact. For example, if you reset the token of a user and then the playbook crashes, and it was supposed to send a notification in Teams or add the user to a specific table, just to have the information, you want to have this information, but you don't want to relaunch the whole playbook because it will reset the token of the user again. This is an example where it is quite important, but the feature is lacking.

Torq can be improved by adding some more features, such as adding more automation and providing a no-code option so I don't have to code for everything. Torq could add API dependency and also on-premise connectivity. If on-premise connectivity is available, organizations wanting to work on Torq could implement it that way.

The only thing is more out-of-the-box integrations. Torq already has a lot of supported integrations and adding new ones is not difficult, but for some customers, it's easier to have a plug and play interface to start onboarding. We didn't evaluate other options because we tested Torq and we liked it. At this stage, I have no additional suggestions. I will update my review several months later and maybe then I will have some suggestions to prove and to what in addition I would like to see in the solution. I can't evaluate Torq's agentic AI, but I think in my next review, I can provide more information.

Torq can probably use more ML and look at what can be closed and what cannot be closed in terms of data classification. In terms of auto closure of incidents, it can do better when it uses ML. I choose that number because it's a great SOAR tool. It's not one of those existing SOAR platforms or just a pure SOAR. It has good incident handling, good UI, and a good user-friendly environment, but it can also improve its automation workbooks, work plans, and usage of ML to better cater to the market or consumers.

I do not dislike anything about Torq because it has satisfied all of our use cases and requirements. We contacted support as well, and support is very good. I believe everything is good now. However, one thing I can mention is that if Torq provided more templates on the development side, that would be beneficial. As of now, Torq satisfies our use cases. A template would be helpful for someone who does not know anything about Torq and is starting to use it for the first time. After conducting a POC on Torq, I can implement solutions without needing templates as much, but templates would serve as a reference for new users. For example, templates would show what is possible with Torq. We faced this issue when we were new to Torq. We were considering use cases but wondering whether they were possible with Torq. At that time, we asked support if it was possible, and they explained how to implement it. If there were default templates available, we could see the templates and understand what is possible and doable with Torq.

Although the reporting within Torq is not that great, we did ask for many features regarding reporting in Torq, but due to some platform constraints, they could not make the whole dataset available for us to be used in reporting. Except for that, we used some basic reporting. 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. 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. The unified view in case management is good since it provides clarity, although there are limitations regarding how many items in case management can be modified at once. Bulk operations are very limited, potentially due to their back-end database or data retrieval processes that can be improved. Regarding improvements for Torq, when we were onboarded, there were aspects we were uncertain about, such as the number of cases that could be generated, what data we could bring in, how many clients we could onboard, and similar concerns. Initially, we also lacked clarity about the number of playbooks or workflows we could build. Different triggers like system triggers, case-based triggers, and others can be employed without restrictions, but when it comes to on-demand and scheduled jobs, there is a limitation based on the subscription and pricing tier that notably caps the number of workflows we can create. No bulk editing across cases was one issue, along with limited filtering related to single grouping constraints. Additionally, the out-of-the-box case templates provided require substantial modifications before they become usable. There is also a feature in the cases for notes that cannot be searched. They are only visible through the UI, which is another area for improvement. The workflow and execution-based charges seem misleading as this was not discussed initially. I am not sure if new customers are made aware of this. It seems that workflows revolving around cases hinder functionality outside of case management, as we have many use cases needing on-demand triggers and schedules for functions like reporting or polling devices. Creating additional workflows to achieve basic functionalities raises costs significantly, which disadvantages customers. While they facilitate optimization and scaling, the support received tends to be very basic. Improvements can be made in that area as well.

To improve alert handling capability, there are ready-to-use playbooks available, but there are very few. Torq should add more playbooks. For example, everyone needs user creation and deletion, and all companies use firewall data. Torq should offer default templates that can directly scan firewall data and automate actions. Additionally, the logging and debugging visibility for what Torq does in the backend is not very visible, so this aspect could be improved.

This is exactly what we discussed two days ago with the Torq team. We told them where we want to see improvements. For example, we have MCP that we are working with our cloud security platform, and we wanted to connect this MCP to the case management. When I go inside a case, I want to have a search bar where I can search details about my cloud and everything in my cloud, details about the specific vendors of the alert, not only the alert itself. Currently, we have a search bar for the alert itself, but we do not have a search bar for the connectors. This is one place for improvement. We already talked about some filtering that they can add. They have a dashboard case dashboard, which is a separate page from the cases itself. We thought about adding a specific widget to the cases page so that we can see statistics inside the cases page. However, there were a few things before that we wanted them to work on, and they have already solved them. For example, we wanted to implement Torq to have access only within our VPN, and as far as I know, they worked on it. A month ago, it succeeded, and we are currently only connecting inside of the VPN.

We do not utilize the AI features that much. When it comes to general AI features of Torq, we are just slowly starting to implement them because I feel that not just Torq, but most companies are just starting to figure out how best they can utilize it. It is not something we have found a lot of value in yet. Personally, I have not utilized it enough. It is a two-way road where I did not see enough value in it and I did not give it enough attention yet. It is not personally the tool we go to for that purpose. It is not something I think we adopted for that purpose. I am not saying it is a pivot of theirs, but because it is something that we have not given enough attention yet, we rely on other tools in our stack to be that center point. We have not used something previously, and Torq has been one of the tools in our growing stack. It is something that is always available as other tools, but we have not picked it internally as our AI SOC tool. Because we have not seen enough value, I cannot give you a lot of information about that. In general, in the niche that Torq is in the market, I think the biggest comparison they get is with N8N. Whenever I see a demo of them or look at a video or documentation, I always say that I would rather pick Torq over it. I feel that it is not just because I am used to it at this point; it was the best way to get into this kind of niche in the market. N8N is not hard and is also easy to get into, but for our use case, Torq, even when we started and it had fewer features than it has now and fewer steps that we can do in the workflow, filled our gap very quickly. It was immediately usable for our use case. That is the strong point. We always strive for more features. I find myself sitting sometimes in front of a workflow wondering why it works this way because it feels like a convoluted way of doing this step. However, it is still something I can do. It is a good point and a bad point about Torq. I do not remember the last time I sat in front of trying to build something in Torq and said to myself that this is impossible and the platform does not allow it. There is always a way to do it. It might just not be the smartest way to do it. When I compare it to a lot of other applications we work with, most of the time, you just cannot do it and it becomes a feature request. Usually, nine out of ten times, if I have a problem with Torq, it is just that I do not the way I need to do something more so than that I just cannot do it. Their AI is an area for improvement. When I heard about them implementing these features and going to agentic approaches, and when they showed us the AI features about a year ago, I became very harsh on AI features in general in the market because every company introduced them without a lot of value in it. Torq has a very difficult game to play where AI steps, on one hand, ruin the point of their workflows, and on the other hand, if implemented well, can be utilized amazingly. When you build a workflow in Torq for at least our use case, you want some sort of rigidity. I want to know that I will always get the same result that I want. The second you put in any AI step, you cannot guarantee that result. If you ask ChatGPT the same question ten times, you might get ten different answers. Torq has a very hard problem of how to implement AI as a model that you use in a step but still get ninety-nine out of one hundred times the result you want, which is usually good enough. Even today, and especially at first, I was not happy with a lot of AI features because I do not see a lot of value in them. Even now, we have workflows that are in production that use AI steps and I get different results, making it unusable to some degree. I try to implement AI steps, give it a couple of runs, and I see that it has about an eighty percent success rate of what I want. I need to go back to rigid steps. It is a good and bad point where I appreciate that they pivot into it, but I do not think it is at a good place right now, at least for our use case, because it negates the point of rigid workflows. There are a lot of small things about Torq where quality of life changes are needed, but that comes with no-code automation in general. Eventually, you build a huge branching tree of steps and it might be hard to navigate and might lag a little because it is huge. It is a very nice UI, but when you build enormous workflows as we do for our use case, it gets hard to navigate sometimes. It is not unusable and easy to jump back into, just hard to maintain. That is the price you pay with no-code automation in general.

Regarding the downsides of Torq, one issue is that as a SaaS product, I sometimes encounter transparency issues about what is going on behind the scenes, necessitating contact with Torq support to get logs in certain situations. From an engineering perspective, I think more error messages and error handling information for our engineering team would be very helpful.

From our research and testing with the tool, we determined there need 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. Regarding data handling, I would give preference to Torq. For case management, Cortex and its dashboards prove more useful. Cortex and Palo's solutions do not have as much capability as Torq provides with the same tools. However, Torq's dashboards could be improved, especially on the case management side.