CIA triad Archives - ozlin.info

Cybersecurity becomes easier to manage when it is translated from technical products into business questions:

What services and information matter?
What could go wrong, and what would the impact be?
Who owns the decision?
Which safeguards are proportionate?
How will we know they are operating?
How will the business respond and recover when prevention is not enough?

These are fundamentals because they remain useful when products, threats and business models change. They also prevent a common mistake: buying a tool before defining the problem it is supposed to reduce.

Begin with business outcomes and risk

A risk discussion needs context. A public brochure website, an accounting platform, a developer's source-code repository and a health-services booking system do not have the same data, dependencies or consequences.

List the activities the business must continue and the technology, people, data and suppliers that support them. For each important scenario, describe the plausible business impact: interrupted delivery, fraudulent payment, lost records, exposed personal information, unsafe decisions, contractual breach or reputational harm. Estimate likelihood only as carefully as the available evidence allows; false precision does not improve the decision.

Record a responsible owner and a chosen treatment. The business might reduce the risk, avoid the activity, transfer some financial consequences through contract or insurance, or consciously accept residual risk. Acceptance should be an informed business decision with a review date—not what happens silently when nobody acts.

NIST describes its Cybersecurity Framework 2.0 as a taxonomy of high-level outcomes for organisations of any size to understand, assess, prioritise and communicate cybersecurity work. The framework is deliberately non-prescriptive: it describes desired outcomes rather than requiring one product or implementation (NIST CSF 2.0).

Confidentiality, integrity and availability

Three enduring security objectives are confidentiality, integrity and availability, often shortened to CIA (NIST glossary). In practical terms:

Confidentiality: information is not disclosed to people or systems that should not receive it. Examples include protecting credentials and limiting access to client records.
Integrity: information and systems are accurate and changed only in authorised ways. Examples include detecting altered bank details, unauthorised website changes or tampered backups.
Availability: authorised users can access the service or information when the business needs it. Examples include recovering invoices after device failure or continuing customer communication during an email outage.

The priorities vary by service. Encryption can protect confidentiality in storage or transit, but it does not ensure that a compromised authorised account uses the data correctly. A backup can support availability, but an untested or attacker-accessible backup may not recover the business. A control should be connected to a specific objective and failure scenario.

Other concepts fit around the same model. Identification claims who a user or system is. Authentication checks that claim. Authorisation decides what the authenticated identity may do. Accountability depends on records that are reliable enough to connect important actions with identities and time. None of these should be described as absolute “non-repudiation” unless the specific technical and legal context supports that conclusion.

Use six functions to avoid prevention-only security

NIST CSF 2.0 groups outcomes into six concurrent functions: Govern, Identify, Protect, Detect, Respond and Recover. Govern was made explicit in version 2.0 because cybersecurity risk belongs in organisational decision-making, alongside operational, financial and reputational risk (NIST CSF 2.0 overview).

For a small business, the functions can be translated as follows:

Govern: set risk ownership, priorities, policy, supplier expectations and relevant legal or contractual obligations.
Identify: know critical assets, data flows, dependencies, vulnerabilities and plausible threats.
Protect: apply safeguards such as MFA, least privilege, secure configuration, patching, backups and staff procedures.
Detect: collect and review useful signals, including privileged sign-ins, backup failures and unexpected account or data changes.
Respond: assess, contain, communicate, preserve evidence and coordinate the people needed during an incident.
Recover: restore services and information, communicate appropriately and improve the plan from lessons learned.

The functions happen together. Recovery cannot wait until after an incident to be designed, and detection cannot be improvised from logs that were never enabled.

Controls need layers, owners and evidence

Controls can be administrative, technical or physical. A payment-fraud risk might be reduced by a written approval process, independent callback, role-based access, email protections and staff reporting. If one layer fails, another can still limit harm.

Avoid treating familiar tools as complete solutions:

A firewall filters defined traffic; it does not make an allowed application secure.
Endpoint security can detect some malicious activity; it does not prove an endpoint is uncompromised.
A VPN protects a connection in particular circumstances; it does not make an untrusted device or fraudulent website safe.
Encryption protects data under defined conditions; it does not correct excessive access or a stolen authorised session.
Training supports decisions; it should not be the only control protecting a high-value payment.

Every important control needs an owner, an expected operating state and evidence. Evidence might be a current access review, a successful restore test, patch-status records, a verified alert, an incident-exercise result or a supplier report. ASD's Essential Eight assessment guidance emphasises credible evidence when assessing both implementation and control effectiveness (ASD's ACSC Essential Eight assessment process guide).

Build a current profile and a target profile

A practical first assessment can fit in a short table:

Business outcome	Current state	Target state	Evidence	Owner	Due date
Important accounts resist password theft	MFA varies by service	MFA on all high-impact accounts; recovery methods reviewed	Provider export and access review	Operations owner	Set locally
Critical records can be restored	Backups report success	A clean restore is demonstrated within the required time	Dated restore-test record	System owner	Set locally
Payment changes are independently verified	Informal checking	Known-number callback and second approval	Sampled approval record	Finance owner	Set locally
Incidents can be escalated	Contacts are scattered	Offline contact list and exercised response plan	Exercise notes and actions	Business owner	Set locally

NIST calls these Current and Target Profiles. Comparing them helps expose gaps and build an action plan aligned with business needs, risk tolerance and resources (NIST CSF frequently asked questions). Do not copy somebody else's target blindly; sector obligations, client contracts, technical complexity and threat exposure can justify a different outcome.

Ask better questions of suppliers and security tools

Before buying a product or managed service, ask:

Which documented risk and target outcome does this address?
What data and administrator access will the supplier receive?
How are privileged actions authenticated and logged?
What happens when the supplier or integration is unavailable?
How are vulnerabilities, incidents and material changes communicated?
Can the business export its data and logs in a usable form?
What evidence will show that the control works after deployment?
Who remains responsible for configuration, monitoring and recovery?

A contract can allocate tasks, but outsourcing does not remove the need to understand critical dependencies. NIST's small-business material similarly recommends considering business objectives, high-value assets, obligations and dependencies before deciding whether to build capability internally or outsource it (NIST small-business team guidance).

Establish a small operating rhythm

Security improves through repeated, owned work:

Monthly: review critical alerts, failed backups, privileged accounts, new integrations and overdue high-priority actions.
Quarterly or risk-based: test a restore, review access, sample payment verification and rehearse one incident scenario.
On material change: review risks when adopting a new SaaS platform, collecting new data, exposing a service to the internet or changing a critical supplier.
After an incident or exercise: record what happened, which assumptions failed and which change has an owner and date.

The related Australian SME cybersecurity baseline turns these principles into an implementation sequence. The phishing response playbook covers one common scenario in more depth.

For help defining a proportionate target state and evidence plan, see Ozlin Info's cybersecurity uplift service or contact Ozlin Info.

General-information disclaimer

This article provides general information only. It is not legal, privacy, insurance, compliance, financial or incident-response advice, and it does not establish that any control set is sufficient for a particular organisation. Appropriate safeguards depend on your data, systems, contracts, sector, threat exposure and risk decisions.

AI-assistance disclosure

AI tools assisted with outlining and copyediting this draft. A human reviewer must verify every factual claim, link, scope statement and publication decision before release. The draft avoids product endorsements and does not promise prevention or compliance.

Primary sources checked

Source access date: 28 August 2026.

Tag: CIA triad

Cybersecurity Fundamentals for Small Business Owners