COGNNA’s Wa’ed backing: who controls the SOC response?

Wa'ed Ventures announced an investment in Saudi cybersecurity company COGNNA on November 8. For a security team considering outsourced monitoring or an AI-assisted security operations centre, the announcement brings a local supplier back into view. The harder decision is what that supplier should be allowed to do when it believes an attack is under way.

COGNNA sells both its Nexus platform and a managed service combining automation with human responders. Its Saudi licensing entry adds an important qualification: the National Cybersecurity Authority lists COGNNA under Tier 2 for managed security operations centre services. Buyers should resolve that service scope before evaluating an impressive demonstration.

Cover: original SultanByte artwork showing security observations passing through an approval boundary before a response action.

What the investment announcement establishes

Wa'ed Ventures' announcement confirms its investment and describes support for COGNNA's next phase of growth. It does not disclose an amount, valuation or new delivery commitment. MENA Startup Digest's November 8 report also says financial terms were undisclosed and attributes the announcement to LinkedIn.

That coverage corroborates the announcement, not product performance. There is no basis here for calculating a new funding total or claiming that the investment has already increased operational capacity.

COGNNA's own product description presents Nexus as an agentic AI security operations platform, available alongside its Smart MDR managed detection and response service. The company describes automated triage, investigation and response supported by its Guardian experts. It also advertises integrations with existing security tools and local data residency.

Those are supplier claims to turn into a delivery schedule. A product demonstration should show which tasks are available in the proposed subscription, which require the managed service and which still depend on the customer's staff. Ask who owns an unresolved alert overnight, rather than assuming that access to a platform includes a staffed response service.

The Saudi licence has a defined boundary

The NCA's registration and licensing page lists COGNNA as a Tier 2 provider of managed security operations centre, or MSOC, services. On the same page, NCA says Tier 2 excludes government entities and entities that own, operate or host critical national infrastructure. Tier 1 has a broader service scope.

This is more useful than an unqualified statement that a company is "NCA licensed." It connects the named supplier to a service category and an eligible customer boundary. It does not establish that every offering from the company falls under the same category, or determine a particular buyer's classification.

A Saudi organisation should have its responsible compliance owner confirm the proposed service, contracting entity and customer eligibility against the current licence and applicable requirements. Do this before the technical pilot becomes a purchasing commitment. A private-sector label alone does not resolve whether an organisation operates or hosts critical national infrastructure.

For a UAE-based group buying services for Saudi operations, keep the Saudi service schedule explicit. A Saudi licence is not evidence of permission, contractual coverage or data handling arrangements for a separate UAE deployment. Review each country's proposed delivery arrangement rather than treating a GCC sales footprint as a common regulatory boundary.

Separate observation from authority to act

An integration can collect alerts without being authorised to isolate a device. An analyst can recommend a response without holding the credentials to execute it. Buyers need to see those distinctions in the configuration, not only in a statement of work.

For an initial pilot, this article proposes four explicit permissions: read telemetry, investigate within an agreed scope, recommend a response, and execute a named action. Assign each separately. Start with a limited set of test assets and require approval for disruptive actions until the organisation has reviewed the evidence and accepted the operational consequences.

NIST SP 800-61 Revision 3, published in April 2025, places incident response within wider cybersecurity risk management. It is useful background for designing responsibilities and recovery arrangements; it is not a Saudi licence or a certification of COGNNA.

The proposed operating record should identify the affected asset, supporting observations, recommended action, approving role and permitted execution window. Where the supplier acts automatically, document the pre-authorised policy and its boundaries. A high confidence score should not silently expand that authority.

Infographic: original SultanByte review framework, November 2026. Sources: NCA's MSOC licensing page, NIST SP 800-61 Rev. 3 and Microsoft Defender response documentation. These are proposed buyer checks, not measured COGNNA results.

Test the business consequence of containment

Device isolation illustrates why response permissions deserve their own review. Microsoft's Defender for Endpoint documentation describes network isolation and release controls, with support depending on the device and configuration. It also warns that isolating a Hyper-V server blocks network traffic to its child virtual machines.

That is Microsoft product behaviour, not evidence that COGNNA invokes that action or handles every listed configuration. If a proposed integration can invoke it, make the exact supported action part of the pilot.

Use synthetic alerts on designated test assets. Confirm which component decides, which identity executes and where the resulting state can be verified. An accepted request is not sufficient evidence that the endpoint changed state. If the device is offline or the action remains pending, the operator must see that uncertainty.

Then test an incorrect recommendation. Can the customer stop the action before execution? If it has already run, who can restore connectivity, and can they do so through a route that remains available? Keep an independently controlled recovery path rather than placing the only recovery credential inside the automation being tested.

Production servers and operational technology need separate treatment from ordinary employee endpoints. Agree exclusions and escalation owners with the teams responsible for those systems. Faster containment is not automatically a better outcome if it interrupts a critical service unnecessarily.

Ask for an evidence pack, not a headline accuracy score

COGNNA's website displays performance and efficiency figures. Do not import them into a business case without the measurement method, workload and exclusions. An alert-triage score does not by itself measure missed incidents, disruptive false positives or time to restore service.

For the pilot, record the relevant timestamps separately: observation received, investigation started, decision approved, action attempted and outcome confirmed. Include cases the system missed or handed back to the customer. Report human effort alongside automated work so a lower alert count does not conceal investigation moved elsewhere.

Review the data path as carefully as the response path. Request a diagram covering collection, storage, model processing, support access and retention. Match the residency promise to the actual deployment and subprocessors. Test a sample evidence export before signing, including whether your team can reconstruct a decision without access to the supplier's dashboard.

For the CTO, the purchase decision should name the customer systems and response powers being delegated. For the security lead, acceptance should require a witnessed action-and-recovery exercise with usable records. Wa'ed's investment is a reason to examine COGNNA's offer; the next commitment should follow a scoped service review and a pilot that proves the customer can still control the response.