WHEN AI CAN ACT, WHO HAS THE AUTHORITY TO STOP IT?

 From Cybersecurity Doctrine to Enforceable Security Architecture

SYDECO Cybersecurity Newsletter — October 2026, Issue 2

Patrick Houyoux — President, PT SYDECO

 

From principle to implementation

In our first October newsletter, we examined a fundamental principle: artificial intelligence can assist human decisions, improve analysis and accelerate complex processes, but responsibility must remain clearly attributable to human authority.

That principle is important. Yet stating it is not sufficient.

The real challenge begins when we attempt to translate it into an operational cybersecurity architecture.

An organization may declare that humans remain in control of artificial intelligence. But what does that mean when an AI-assisted system detects suspicious activity, recommends intervention, or is connected to mechanisms capable of interrupting a process or isolating a machine?

 

Who authorizes the intervention? Who verifies that the authorization is legitimate? Who can reverse the action? And who remains accountable if the system makes a mistake?

 

These are not merely philosophical questions.

They are engineering questions.

Detection is not authority

Modern cybersecurity systems can collect enormous quantities of information, correlate events, detect anomalies and identify potential threats far faster than a human analyst.

Artificial intelligence can contribute significantly to this work.

But detecting a potential threat does not automatically justify taking disruptive action.

A suspicious process is not necessarily a malicious process. An unusual network connection is not necessarily an attack. An anomaly score is not a legal or operational authorization.

Confusing detection with authority creates a dangerous situation: technology may begin making consequential decisions without the necessary institutional controls.

 

At SYDECO, we believe that cybersecurity architecture must distinguish four essential functions:

Detection: What is happening?

Analysis: What does the available evidence suggest?

Authorization: Who is entitled to approve an intervention?

Controlled response: What action may be executed, under which conditions, and with what possibility of verification or reversal?

These functions may operate within one integrated system, but they must not lose their distinct responsibilities.

 

Human control must exist inside the architecture

 

Human oversight is sometimes presented as a simple requirement for an operator to click an approval button.

That is not enough.

A credible security architecture must verify the identity and authority of the person approving an action.

 

It must prevent unauthorized escalation, distinguish observation from intervention and maintain records of decisions and their execution.

For particularly sensitive actions, separation of duties may be necessary: one person proposes the intervention, while another independently authorizes it.

The system must also recognize uncertainty.

 

If an AI component cannot provide a reliable assessment, it should not manufacture confidence or silently substitute another decision mechanism.

Equally important, a security system must be capable of explaining what action was requested, what was authorized, what actually happened and whether the intended technical result was achieved.

 

Human Oversight: An Internationally Recognized Security Principle

 

This principle is not confined to SYDECO's own cybersecurity doctrine.

 

In the United States, the National Institute of Standards and Technology (NIST), through its Artificial Intelligence Risk Management Framework, emphasizes the importance of defining human responsibilities, establishing oversight mechanisms and ensuring accountability throughout the AI system lifecycle.

 

Its approach recognizes that the appropriate degree of human intervention depends on the nature and risks of the decisions involved.

 

This distinction is fundamental.

 

Not every automated security operation requires individual human approval. Routine monitoring, data collection and preliminary analysis can operate automatically within predefined policies.

 

However, when a system is capable of taking actions that may disrupt operations, affect availability or produce significant consequences, the question of authorization becomes critical.

 

The issue is therefore not whether artificial intelligence should operate autonomously.

 

The issue is who defines the limits of that autonomy, who authorizes consequential interventions, and how those limits are technically enforced.

 

This international perspective reinforces SYDECO's conviction that effective cybersecurity is not simply about developing increasingly intelligent systems.

It is about developing systems whose intelligence operates within a clearly defined framework of human authority and organizational accountability.

 

Accountability cannot be added afterward as a reporting feature. It must be designed into the system itself.

Sovereignty is also an architectural decision

 

There is another dimension to this discussion: the location and control of the analysis.

Increasingly, organizations send operational information to external services for interpretation.

Depending on the information concerned, that practice may introduce questions about confidentiality, jurisdiction, data exposure and dependence on external infrastructure.

 

Cloud processing is not inherently insecure. However, organizations dealing with sensitive information should have the ability to decide where their data is processed and who controls the infrastructure.

 

Local AI processing can help maintain that control.

It allows security analysis to be performed within the organization's defined infrastructure, reducing the need to transmit sensitive telemetry to external AI providers.

 

For SYDECO, digital sovereignty is not simply a matter of national preference.

It is a question of enforceable technical control.

 

From doctrine to engineering: RISKIPSO

 

For more than a decade, SYDECO has developed cybersecurity technologies around the principles of prevention, visibility, controlled access and protection of information systems.

 

Our current RISKIPSO development extends this philosophy into AI-assisted security operations.

 

RISKIPSO is being engineered to connect security detection and analysis with explicitly controlled response mechanisms.

 

Its local AI analysis uses SYDECO LightML, avoiding reliance on external AI services for the verified analysis pipeline.

 

Within the currently validated implementation, AI provides advisory analysis. It does not independently acquire authority to execute disruptive actions.

 

Selected response operations are protected by a two-person authorization mechanism, and execution events are recorded with technical audit evidence.

 

These are engineering mechanisms already tested in the development environment. Further integration and operational qualification are continuing before commercial release.

 

The purpose of mentioning RISKIPSO is not to present another artificial intelligence product as a universal solution. It is to demonstrate that the principles we defend can be translated into technical mechanisms.

Detection can be automated.

Analysis can be accelerated.

But authorization must remain subject to enforceable rules, and execution must remain accountable.

 

The question every organization should ask

The most important question is not whether an organization uses artificial intelligence.

Nor is it whether the system is sufficiently autonomous.

The question is whether its authority is defined, technically restricted and auditable.

Can the organization determine what the system may observe?

Can it restrict what the system may recommend or execute?

Can it identify who authorized a consequential action?

Can it verify the result?

And can it intervene when something goes wrong?

If these questions cannot be answered, the organization may possess sophisticated technology without possessing effective control over it.

 

Our conclusion

 

Artificial intelligence will continue to transform cybersecurity. It will make detection faster, analysis more sophisticated and security operations potentially more effective.

But speed is not authority.

Intelligence is not accountability.

And automation is not governance.

 

At SYDECO, our conviction remains unchanged:

The purpose of cybersecurity technology is not to replace human responsibility. It is to strengthen the ability of responsible people to protect the systems entrusted to them.

 

A security system should never possess more authority than the organization has deliberately granted to it.

 

That is the difference between merely deploying artificial intelligence and designing a security architecture that deserves trust.

 

Patrick Houyoux
President — PT SYDECO
Yogyakarta, Indonesia

Cybersecurity by Design. Sovereignty by Architecture. Human Authority by Principle.

 

#Cybersecurity #AIGovernance #HumanOversight #DigitalSovereignty #SOC #SOAR #RISKIPSO #SYDECO

 

AI IS NOT A NEW CYBER UNIVERSE. IT IS A NEW ACTOR INSIDE THE EXISTING ONE.

Long before artificial intelligence appeared, intelligence was already a concept through which humanity tried to understand organisation, adaptation and complexity, from the largest structures we observe in the universe to the smallest mechanisms of life.

Order and disorder coexist. What we sometimes call chaos does not necessarily mean the absence of organisation; it can be part of systems whose complexity exceeds our immediate understanding. Human beings themselves are part of those systems.

When we began developing what we now call Artificial Intelligence, the objective appeared relatively straightforward: create tools capable of helping us solve problems, accelerate calculations, analyse information and perform tasks that would otherwise require considerable human time.

But AI did not remain simply a sophisticated calculator.

Its role expanded extraordinarily quickly.

Today, artificial intelligence is entering virtually every sector of human activity: science, education, finance, medicine, industry, administration, communication and, of course, information technology and cybersecurity.

Its presence has become so significant that AI education is already being introduced at very early stages of schooling in countries such as China.

The important change, however, is not simply that AI is becoming more widely used.

The important change is what AI is increasingly allowed to do.

AI is no longer only generating text, images, predictions or recommendations.

It is being integrated into existing workflows, applications and infrastructure. It can analyse events, use tools, access information, interact with software, initiate processes and, under certain architectures, trigger actions that previously required a human operator.

This distinction is fundamental.

There is a major difference between:

AI that advises a human being

and

AI that can act inside an information system.

The second is no longer merely an analytical tool.

From a cybersecurity perspective, it becomes an operational actor.

And once AI becomes an actor, the security question changes.

The question is no longer simply:

“How do we protect the AI?”

It must also become:

“What is the AI authorised to do?”

An AI agent may receive credentials.

It may communicate with applications.

It may query databases.

It may initiate automated workflows.

It may interact with cloud infrastructure.

It may participate in security operations.

It may recommend, or eventually execute, responses to cyber incidents.

These capabilities can produce enormous benefits.

They can also create a new concentration of privilege inside the information system.

And this is precisely why AI should not be treated as if it were creating an entirely new cybersecurity universe requiring us to forget everything learned during decades of information-security engineering.

The opposite is true.

AI is entering the existing cyber environment.

Therefore, the fundamental principles remain.

Identity.
Authentication.
Authorisation.
Access control.
Segmentation.
Least privilege.
Monitoring.
Accountability.
Auditability.
Zero Trust.

The difference is that these principles must now also apply to AI.

If an AI system accesses sensitive information, its identity must be known.

If it performs an action, that action must be attributable.

If it accesses a network segment, that access must be authorised.

If it attempts to exceed its permissions, the system must prevent it.

If its behaviour becomes abnormal, that behaviour must be detected.

And if an important decision can affect infrastructure, data, security or people, there must remain a clearly defined mechanism of human authority and accountability.

This is particularly important because speed is one of AI's greatest advantages, and potentially one of its greatest risks.

A human operator may make one incorrect action.

An automated agent connected to multiple systems can reproduce an incorrect action almost instantaneously across an entire environment.

Automation therefore does not reduce the importance of cybersecurity governance.

It increases it.

This is why the current debate about AI should not lead us to abandon established cybersecurity architecture in favour of fashionable terminology.

We do not need to reinvent cybersecurity every time technology introduces a new actor.

When employees received access to corporate systems, we created identity and access controls.

When mobile devices entered enterprise networks, we adapted security policies.

When cloud infrastructure expanded, we extended identity, monitoring and Zero Trust principles to it.

AI should be approached with the same architectural discipline.

The technology is new.

The fundamental security problem is not.

It remains the management of trust, identity, privilege, access and responsibility.

Artificial Intelligence can become an extraordinary accelerator of human capability.

But the more authority we delegate to it, the more precisely its authority must be defined.

AI should therefore not stand outside our cybersecurity architecture.

It must exist inside it, under control, under observation, and within clearly defined boundaries.

Because AI is not a new cyber universe.

It is a new actor inside the existing one.

 

Yogyakarta 12 October 2026

 

Patrick HOUYOUX LL.M.

President-Director PT SYDECO

CYBERSECURITY SHOULD NOT START WITH A PRODUCT NAME. A SYDECO Doctrine on Detection, Decision, Response and Human Authority

 Introduction

Cybersecurity has acquired an increasingly complex vocabulary.

SOC. SOAR. SIEM. XDR. Zero Trust. AI-driven detection. Automated remediation. Threat intelligence. Orchestration. Behavioural analytics.

These concepts are important. They describe genuine technological progress.

But terminology can also become a distraction.

A cybersecurity architecture should not begin by asking:

Which SOC should we buy?
Which SOAR platform should we deploy?
Which internationally known vendor should we select?

It should begin with a more fundamental question:

What must happen, operationally, from the moment a suspicious event appears until the organization has detected it, understood it, attributed it, decided what to do, acted safely, and preserved the evidence?

This is the foundation of the SYDECO doctrine.

For more than a decade, PT SYDECO has worked on cybersecurity systems in which detection, segmentation, control and response are integrated directly into the defensive architecture.

Many capabilities that are today described using the terminology of SOC, SOAR, Zero Trust and automated cyber response were already present as operational functions within our products and security architecture, even when we did not use those names commercially.

The terminology evolved.

The fundamental security problem did not.

1. SECURITY IS A PROCESS, NOT A PRODUCT

An organization is not secure because it owns a firewall.

It is not secure because it has installed a SIEM.

It is not secure because it operates a SOC.

And it is not secure simply because a SOAR platform can execute automated playbooks.

Security exists only when an organization can reliably complete the entire chain:

Observe → Detect → Understand → Attribute → Decide → Authorize → Act → Verify → Preserve Evidence

If one of these stages fails, the architecture is incomplete.

A sophisticated detection system that generates alerts but produces no timely response is insufficient.

An automated response engine capable of acting without reliable attribution is dangerous.

A SOC receiving millions of events without prioritization creates visibility but not necessarily security.

A SOAR platform executing poorly designed playbooks can automate mistakes faster than a human team could make them manually.

The objective must therefore be the integrity of the complete operational chain.

2. WHAT A SOC REALLY REPRESENTS

The Security Operations Centre is often understood as a room, a platform or a team.

From an architectural perspective, however, its function is broader.

A SOC must provide the organization with the capacity to:

• observe security-relevant events;
• aggregate information from multiple sources;
• distinguish normal activity from suspicious activity;
• correlate events;
• assess severity;
• identify affected assets and users;
• support investigation;
• establish operational context;
• escalate the event;
• support a decision;
• maintain traceability.

This means that the SOC is fundamentally an observation and decision-support capability.

The quality of a SOC cannot therefore be measured only by the number of dashboards it displays or the volume of data it collects.

Its real value is measured by whether it produces information that can support a correct security decision in time.

3. WHAT SOAR REALLY REPRESENTS

SOAR — Security Orchestration, Automation and Response — addresses the next stage.

Once the security situation has been understood, something must happen.

The response may include:

• isolating an endpoint;
• blocking an IP address;
• disabling credentials;
• modifying access rights;
• changing firewall policy;
• isolating a network segment;
• terminating a session;
• escalating an event;
• creating an incident record;
• collecting forensic evidence;
• notifying responsible personnel;
• launching additional verification.

SOAR therefore represents the execution layer between decision and action.

But automation alone is not the objective.

The objective is:

Controlled, justified, traceable and reversible security action.

That distinction is fundamental.

4. THE CENTRAL PROBLEM IS NOT SOC OR SOAR

The industry frequently separates the technology into categories.

One vendor provides the firewall.

Another provides endpoint detection.

Another provides SIEM.

Another provides orchestration.

Another provides identity management.

Another provides threat intelligence.

Another provides artificial intelligence.

All of these technologies can be excellent.

But cybersecurity performance is not automatically created by assembling excellent individual products.

The central problem is the interfaces between them.

How quickly does information move?

How reliably is identity established?

How does one component know that another component has completed an action?

What happens when a system is unavailable?

Who is allowed to authorize a high-impact response?

Can an action be reversed?

Was the evidence preserved before containment?

Can an auditor later reconstruct what occurred?

This is why SYDECO does not consider SOC and SOAR as isolated products.

We consider them parts of a larger cyber-response architecture.

5. SYDECO'S ARCHITECTURAL APPROACH

Since its creation, SYDECO has concentrated on integrated cybersecurity.

ARCHANGEL was not conceived merely as a firewall.

Its architecture incorporates or coordinates multiple defensive functions, including:

• network intrusion detection;
• intrusion prevention;
• deep packet inspection;
• network monitoring;
• host monitoring;
• honeypot mechanisms;
• VPN security;
• segmentation;
• micro-segmentation;
• policy enforcement;
• access control;
• traffic inspection;
• security-event generation;
• Zero Trust principles.

The objective has always been to move security controls closer to the point where security decisions must actually be enforced.

This is important because the farther the response mechanism is separated from detection, the greater the risk of delay, inconsistency or loss of context.

SYDECO therefore favours an architecture in which:

Detection and enforcement remain operationally close.

6. FROM ALERT-BASED SECURITY TO RESPONSE-BASED SECURITY

Traditional cybersecurity systems often follow this sequence:

Event → Alert → Analyst → Investigation → Decision → Manual Action

This remains necessary for complex incidents.

But it is inefficient for known and repeatable situations.

Modern cyber defense must therefore support another model:

Event → Validation → Decision → Controlled Response

This does not mean removing humans.

It means separating events according to the level of confidence, impact and authority required.

Some actions may be completely automated.

Others may require human validation.

Others must never be automated without explicit authorization.

This produces a layered response model.

7. THE PRINCIPLE OF REVIEW-GATED RESPONSE

SYDECO's doctrine rejects the simplistic idea that maximum automation automatically produces maximum security.

A response must be proportionate to its potential impact.

For example:

Automatically collecting additional telemetry may present little operational risk.

Automatically blocking a clearly malicious source may present moderate risk.

Automatically disabling a privileged account may have significant operational consequences.

Automatically disconnecting an industrial or critical operational system may be unacceptable without human review.

For this reason, SYDECO uses the principle of:

REVIEW-GATED RESPONSE

The system may automatically:

• detect;
• correlate;
• classify;
• calculate confidence;
• gather evidence;
• recommend action;
• prepare the response.

But high-impact action can remain subject to explicit human authorization.

This creates an important division:

Machine speed for analysis.
Human authority for consequential decisions.

This is not a limitation of automation.

It is responsible automation.

8. IDENTITY MUST PRECEDE ACTION

One of the greatest weaknesses in automated security is incorrect attribution.

A system may detect suspicious activity.

But before taking a disruptive action, it should understand:

• which device is involved;
• which user is involved;
• which network segment is involved;
• which session is involved;
• which asset is involved;
• what privilege level is involved.

Security response without identity creates the risk of acting against the wrong target.

For this reason, SYDECO's architecture emphasizes strong identity binding before high-impact response.

The principle is simple:

Do not automate serious action against something you have not identified with sufficient confidence.

This is particularly important in large organizations where users, devices, servers, applications and network zones interact continuously.

9. SEGMENTATION IS ALREADY A FORM OF ORCHESTRATED RESPONSE

One reason SYDECO does not consider SOAR entirely new is that security architectures have long contained forms of automated response.

Segmentation is an example.

When a system enforces that one network sector may communicate with another only under specific rules, the architecture is already transforming policy into automatic action.

Micro-segmentation goes further.

VPN isolation does the same.

Dynamic blocking does the same.

IDS/IPS enforcement does the same.

Access-control rules do the same.

In each case:

A condition is evaluated and a security action follows.

What modern SOAR adds is broader coordination across multiple systems and a formalized workflow for those actions.

The concept is therefore evolutionary rather than revolutionary.

10. THE IMPORTANCE OF THE ENFORCEMENT POINT

A security decision has value only if it can be enforced.

This is one of the reasons the network-control layer remains critical.

Consider a malicious session.

A SOC may detect it.

A SIEM may correlate it.

Artificial intelligence may classify it.

A SOAR platform may recommend blocking it.

But ultimately something must terminate, isolate or restrict the traffic.

The enforcement point may be:

• a firewall;
• a network gateway;
• an endpoint agent;
• an identity provider;
• a VPN gateway;
• a segmentation mechanism;
• an application-control system;
• an encryption-key authority.

SYDECO's philosophy is therefore that intelligence and enforcement should be architecturally connected.

Detection without enforcement is observation.

Enforcement without intelligence is rigidity.

Cyber defense requires both.

11. THE ROLE OF ARTIFICIAL INTELLIGENCE

Artificial intelligence can considerably improve cyber defense.

It can help:

• prioritize events;
• identify abnormal behaviour;
• correlate weak signals;
• summarize incidents;
• classify threats;
• recommend responses;
• reduce analyst workload;
• accelerate investigation.

But AI should not become an uncontrolled security authority.

SYDECO's position is clear:

AI can support the security decision. It should not automatically become the sovereign decision-maker.

AI may calculate.

AI may classify.

AI may recommend.

AI may prepare.

But organizational authority must remain governed.

This becomes increasingly important as AI systems gain the ability to call APIs, execute scripts, change configurations and interact directly with security infrastructure.

An AI system capable of acting must itself be treated as a privileged actor.

12. SECURITY AUTOMATION MUST BE GOVERNED

Any automated response architecture should answer at least the following questions:

Who requested the action?

What triggered it?

Which evidence justified it?

What confidence level was assigned?

Which system approved it?

Was human authorization required?

Which system executed it?

When was it executed?

Was execution successful?

What was the operational effect?

Can the action be reversed?

Was all evidence preserved?

Without these answers, automation becomes operational opacity.

With these answers, automation becomes governed response.

This distinction is essential.

13. EVIDENCE IS PART OF THE RESPONSE

Incident response should never destroy the information required to understand the incident.

This sounds obvious.

In practice, aggressive containment may remove precisely the evidence investigators need.

The correct sequence may therefore sometimes be:

Detect → Preserve → Validate → Contain

rather than simply:

Detect → Block

For this reason, evidence preservation is part of SYDECO's response doctrine.

A cyber-response architecture should maintain:

• timestamps;
• event records;
• triggering conditions;
• identities;
• actions;
• approvals;
• response results;
• integrity verification.

This allows the organization to reconstruct an incident later.

That is important operationally, legally and for governance.

14. AUDITABILITY IS NOT ADMINISTRATION — IT IS SECURITY

Cybersecurity systems increasingly operate in regulated environments.

As automation increases, organizations must be capable of explaining what their systems did.

A security architecture therefore requires an audit trail.

The organization should be able to answer:

What happened?

Why did the system consider it suspicious?

What decision was made?

Who or what authorized the response?

What action occurred?

What was the result?

If those questions cannot be answered, the organization may possess powerful technology but weak governance.

15. INTEGRATION WITH EXISTING INFRASTRUCTURE

A mature cybersecurity project should not automatically require an organization to discard infrastructure that already works.

Existing SOC systems, SIEM platforms, Wazuh deployments, identity systems, network controls and operational processes may remain valuable.

The objective should therefore often be integration rather than replacement.

The question becomes:

How can the existing environment be made more responsive, more integrated and more governable?

This is particularly important for large organizations.

Replacing a complete security ecosystem creates:

• operational risk;
• migration risk;
• training requirements;
• new dependencies;
• integration complexity;
• substantial cost.

An architecture capable of strengthening existing systems can therefore provide strategic value far beyond the acquisition cost of an additional platform.

16. SOVEREIGNTY AND CONTROL

Cybersecurity architecture increasingly raises questions beyond technical performance.

Organizations must also consider:

• where data is processed;
• who can access telemetry;
• where security logs are stored;
• which external services are required;
• whether the system remains operational without foreign cloud dependencies;
• whether security policies remain under organizational control.

For government bodies, state companies and critical infrastructure, these questions are particularly important.

SYDECO therefore considers sovereignty a technical design requirement, not merely a political concept.

A sovereign security architecture should allow an organization to retain effective control over:

Data.

Identity.

Policy.

Decision.

Response.

17. PROJECT 2 AS AN APPLICATION OF THE DOCTRINE

Project 2 should therefore not be understood merely as the installation of another security product.

Its objective is to construct an operational cyber-response capability around the client's existing infrastructure.

The architecture is based on several principles developed throughout this doctrine:

Existing security infrastructure remains useful.

The project integrates with the existing SOC/Wazuh environment rather than unnecessarily replacing it.

Detection must become actionable.

Events must be transformed into validated response workflows.

Identity must be established before major action.

Response must be connected to the correct user, system, asset and session.

Automation must be proportional.

Low-risk actions can be automated.

High-impact actions can remain review-gated.

Human authority must be preserved.

Technology accelerates the decision process without removing institutional responsibility.

Evidence must be preserved.

Detection, validation, approval and enforcement must remain auditable.

Response must be enforceable.

Security decisions must reach effective technical control points.

The architecture must remain understandable.

A cybersecurity system that cannot be explained cannot be effectively governed.

18. THE REAL DELIVERABLE

The real deliverable of an advanced cybersecurity project is therefore not simply:

a dashboard,

a SOC platform,

a SOAR license,

an AI engine,

or another firewall.

The real deliverable is:

THE ABILITY TO MOVE FROM TRUSTWORTHY DETECTION TO CONTROLLED ACTION.

This capability requires technology.

But it also requires architecture.

It requires identity.

It requires governance.

It requires evidence.

It requires operational discipline.

And it requires a clear understanding of where automation should stop and institutional authority should begin.

19. LARGE VENDORS AND SPECIALIZED ARCHITECTURE

Global cybersecurity vendors have created remarkable technologies.

Their platforms are deployed across some of the world's largest organizations.

That expertise should be recognized.

But the existence of excellent global vendors does not remove the need for architecture adapted to a particular organization.

Cybersecurity should never become a contest of logos.

A globally successful platform may still require:

• local integration;
• operational adaptation;
• policy design;
• response engineering;
• identity integration;
• network adaptation;
• governance;
• evidence management.

Technology must serve the organization's security architecture.

The architecture should not be distorted merely to accommodate technology.

20. TEN YEARS OF CONTINUITY

The cybersecurity industry changes rapidly.

Names change.

Products change.

Attack methods change.

Artificial intelligence introduces new capabilities.

But several principles remain remarkably stable:

Know what is connected.

Know who is acting.

Control what they can reach.

Observe abnormal behavior.

Reduce unnecessary privilege.

Segment systems.

Verify identity.

Detect intrusion.

Respond proportionately.

Preserve evidence.

Maintain authority.

These principles have guided SYDECO's development for more than a decade.

Modern SOC and SOAR architectures do not invalidate those principles.

They provide new mechanisms for implementing them.

 

CONCLUSION

The cybersecurity debate should move beyond product categories.

The real question is no longer:

Do we have a SOC?

or:

Do we have SOAR?

The real questions are:

Can we detect what matters?

Can we identify who or what is responsible?

Can we determine the correct response?

Can we execute that response safely?

Can we preserve human authority where necessary?

Can we prove afterward exactly what happened?

That is the architecture that matters.

The future of cybersecurity will not belong simply to the organization with the largest SOC, the most famous SOAR platform, or the longest list of security products.

It will belong to organizations capable of converting trustworthy detection into the right decision, the right response and verifiable evidence — while preserving human authority where it matters.

That is the doctrine behind SYDECO's approach to modern cyber defense.

And it is the philosophy behind Project 2.

 Don't miss our technical demos of our doctrine, on Linkedin, every day at 7.345 and 18 and on WA at 12.00!

Patrick Houyoux LL.M.
President — PT SYDECO

Cybersecurity architecture should begin with the problem to be solved — never with the name of the product intended to solve it.