Memory(One)
Get in touch
Back to insights

Security & Maintainability

Operational security beats symbolic control

Data location matters, but real control depends on access, logging, monitoring, backup, recovery, dependency health and operational ownership.

Published
  • Cloud, DevOps & Operations

Data location matters, but it is not the same as control.

A company can move data to a preferred hosting location and still have weak access control, poor logging, untested backups, outdated dependencies, unclear recovery procedures and limited visibility into how systems are used.

That is symbolic control. Operational security is different.

Operational security asks whether the company can understand, limit, monitor, maintain and recover the systems it depends on.

The difference between residency and control

Data residency describes where data is stored or processed. It can be important for contracts, policy, procurement and regulatory reasons.

Operational control asks different questions:

  • Who can access the system and data?
  • How are permissions granted and reviewed?
  • Which integrations can read or write data?
  • What logs exist?
  • How are dependencies patched?
  • How are secrets managed?
  • Are backups tested?
  • Can the company detect unusual activity?
  • What happens when an integration, workflow or AI agent behaves incorrectly?
  • Who owns the system after launch?

A serious software decision should consider both. But a location decision alone does not create security.

Cloud responsibility is shared

Major cloud providers describe security as a shared responsibility. AWS states that security and compliance are shared between AWS and the customer. Microsoft’s shared responsibility guidance similarly explains that customers remain responsible for protecting their data, identities and the cloud components they control, with responsibility varying by service type.

The practical lesson is simple: moving to cloud, moving from cloud or choosing a local provider does not remove the need for operational discipline.

The business still needs to manage applications, users, permissions, configuration, code, data, integrations, dependencies, monitoring and recovery.

What operational security includes

Access control

Access should be based on roles and business need. Users, administrators, service accounts, integrations and AI workflows should have only the permissions required.

Permissions should be reviewed periodically, especially when employees change roles, suppliers leave or systems are connected in new ways.

Logging and monitoring

Important systems should produce useful logs. Logs should help answer what happened, who did it, what data was accessed, which integration ran and where failures occurred.

Monitoring should identify issues early: failed jobs, unusual usage, integration errors, authentication problems, performance changes and unexpected cost or volume increases.

Dependency health

Many application risks come from outdated frameworks, libraries, runtime versions and infrastructure components. Dependency review and patching are part of maintainability, not an occasional crisis task.

Backup and recovery

Backups are only useful if they can be restored. Operational security includes knowing what is backed up, how often, where backups are stored, who can access them and whether recovery has been tested.

Deployment discipline

Manual, undocumented deployment increases risk. Clear deployment processes, environment separation, rollback plans, configuration management and release documentation reduce operational uncertainty.

Integration visibility

Integrations can become hidden risk. They move data between systems, often through credentials that remain active for years. A review should identify what integrations exist, what they can access and what happens when they fail.

AI and agent controls

AI workflows add new control questions. Which data can the model see? Which tools can an agent call? Are outputs reviewed? Are prompts and retrieval sources logged? Are costs monitored? Can the workflow be stopped?

OWASP highlights risks such as prompt injection, sensitive information disclosure and excessive agency in LLM applications. ENISA’s 2025 Threat Landscape also describes fraudulent websites impersonating AI tools to deliver malware and targeting of the AI supply chain.

AI is therefore not separate from operational security. It extends the same questions into new workflows.

NIS2 and engineering discipline

The NIS2 Directive establishes a cybersecurity framework across 18 critical sectors in the EU. Not every company will be directly in scope, and legal applicability should be checked separately. But the direction is clear: cybersecurity is increasingly treated as a governance and operational risk issue, not only an IT issue.

For software teams, this reinforces practical engineering habits: access control, logging, incident visibility, patching, backup, recovery, supply-chain awareness and clear ownership.

This article is not a NIS2 compliance guide. It is a reminder that good operational software practice and risk visibility are becoming more important.

Questions worth asking

A practical operational security review can start with simple questions:

  • Which systems are business-critical?
  • Who owns each system technically and operationally?
  • Who has administrator access?
  • Are service accounts documented?
  • Which integrations have write access?
  • Are secrets stored safely?
  • Which dependencies are outdated?
  • How are security updates applied?
  • What logs are available?
  • Are backups tested?
  • What is the recovery process?
  • Which AI tools or agents can access business data?
  • What would be difficult to explain if something went wrong?

The answers usually reveal whether the organisation has real control or only assumed control.

Boundaries of a Technical Review

A Technical Review can identify practical security risks, dependency exposure, access-control weaknesses and operational gaps. It can help prioritise improvements and create a roadmap for safer operation.

It is not a substitute for formal penetration testing, specialist incident response, compliance certification, legal advice or sector-specific security audit unless those are separately scoped with appropriate specialists.

The distinction matters. Memory(One)’s role should be practical security improvement as part of software engineering, modernisation and operation — not unsupported cybersecurity claims.

The practical takeaway

Operational security beats symbolic control because it deals with what systems actually do.

Where data is hosted matters. But access, logging, monitoring, patching, backup, recovery, integration visibility and ownership decide whether the business can trust, maintain and recover the software it depends on.

Sources and inspiration

Next step

Need a practical route from article topic to working software?

Memory(One) helps organisations review, modernise and build the systems their teams depend on.

Get in touchView servicesRequest a Technical Review