Security by Design: Security Starts with Architecture

A new application can have polished design, smooth onboarding, OTP authentication and an AI assistant that feels intelligent.

Yet some of its most important security questions appear before the first interface is finished:

What data does the system actually need? Who should see it? And what should they be allowed to do once access is granted?

On 20 August, Indonesia's Ministry of Communication and Digital Affairs promoted security by design as the threat landscape becomes increasingly influenced by AI. The principle is straightforward: security should be embedded while technology and business processes are being designed, rather than addressed only after an attack.[1]

That shifts security from the final stage before launch into product architecture itself.

Secure login does not make the whole system secure

Cybersecurity discussions often focus on authentication.

Use stronger passwords.

Add OTP.

Enable multi-factor authentication.

All are useful.

But a user who successfully enters an application should not automatically be able to see everything inside it.

Consider a sales platform containing customer information.

Sales staff may need contact details and lead status.

A supervisor may need aggregated performance.

Finance may need payment information.

Customer service may need a specific order or policy.

Security by design asks a simple question:

Why should every role see information that is irrelevant to its job?

Least-privilege access turns that into an architectural decision rather than an administrative clean-up exercise.

International secure-by-design guidance similarly encourages manufacturers to make secure configurations, stronger authentication and useful audit logs integral to products rather than pushing most of the burden onto customers.[5]

Data you never collect cannot leak from your database

Security begins even earlier than access control.

It begins with:

Do we need to collect this information at all?

The more information a company stores, the more information it must protect.

Indonesia's Personal Data Protection Law requires controllers to protect personal data from unauthorised access and other unlawful processing.

That makes early collaboration between product, privacy, legal, security and operations increasingly valuable.

The right time to ask why a data field exists is before a database contains millions of records.

When AI can act, permission becomes critical

The issue becomes more significant when AI moves beyond providing recommendations.

On 6 August, the ministry highlighted systems capable of planning and executing actions—including transactions, data changes and automated approvals.[2]

Consider an AI sales assistant.

Summarising a customer record may carry relatively limited operational impact.

But what if the same AI can:

send a customer message;

change an address;

issue a discount;

approve a refund;

delete a record;

or authorise a transaction?

Governance can no longer ask only:

“Was the AI's answer accurate?”

It must also ask:

“What is this AI authorised to do, under which conditions, and who approves higher-impact actions?”

AI needs permission boundaries just as human users do.

Automation needs risk-based checkpoints

Not every automated task should require human confirmation.

If a person must approve every routine action, much of automation's value disappears.

But risk differs.

Classifying an email is not equivalent to changing a customer's bank account.

One useful product-design model is:

observe — the AI reads or analyses;

recommend — it suggests;

prepare — it prepares an action;

execute — it performs an action;

approve — it makes a consequential decision.

As impact increases, stronger thresholds, logging, rollback capability and, where appropriate, human oversight become more valuable.

This is a GATICORP editorial model, not an official regulatory classification.

Logging is the system's memory

When an incident occurs, basic questions quickly follow.

Who accessed the information?

What changed?

When?

Through which account?

Was the action performed by a person, an API or an AI system?

Without adequate audit logs, investigation becomes reconstruction by inference.

Security by design therefore includes deciding which actions must be recorded, how long records remain available, who can read them and how they are protected from manipulation.

Auditability is rarely the most visually exciting product feature.

During an incident, it may become one of the most valuable.

Design systems to fail well

Security should not be confused with a promise that nothing will ever go wrong.

A resilient design assumes that part of the system may eventually fail.

Credentials may be stolen.

A vendor can experience an outage.

Storage can fail.

People make mistakes.

The next question becomes:

How quickly can the organisation recover?

A backup that has never been restored in testing is not the same as proven recovery capability.

An incident plan that has never been exercised may behave differently under real pressure.

Resilience is part of product quality.

Future threats influence today's architecture

The ministry has also highlighted the concept of harvest now, decrypt later: encrypted information could be collected today in the hope that future technology can decrypt it.[3]

NIST has already finalised core post-quantum cryptography standards and encourages organisations to identify where vulnerable algorithms are used and plan migration.[4]

That does not mean every small business needs to replace its cryptographic stack immediately.

A more practical first step is understanding cryptographic exposure and data longevity.

Which information must remain confidential for five years?

Ten years?

Twenty?

Security priorities should reflect how long information retains value.

Five layers of security by design

As a GATICORP editorial framework, digital product teams can begin with five layers.

Data

What is collected, why is it needed, and how long will it remain?

Identity

How are people, services, devices and AI systems identified?

Permission

Who—or what—is allowed to see and change each resource?

Workflow

Which actions can be automated and which require additional control?

Recovery

How will the organisation detect, contain, reconstruct and recover from failure?

No framework can eliminate risk.

But there is a substantial difference between security that begins with architecture and security discovered as a requirement after launch.

Product teams commonly ask:

“What else can this system do?”

Security by design introduces another useful question:

“What should this system never be allowed to do?”

That second question can be what makes the product more mature.