InnoAxis content

Monday morning!

It is Monday morning. Your employees can sign in to their computers. The internet works. Email is available. But the outside service you need to run payroll, retrieve client files or send invoices will not load.

Your own network may be working exactly as intended. Your business still has a problem: an essential part of the work happens somewhere else.

Who checks the provider’s status? Who decides whether to switch to a manual process? Can you reach employees if your usual collaboration platform also becomes unavailable? And what can you confidently tell clients?

For Canadian SMBs, cybersecurity planning needs to include these dependencies. A practical starting point is a 30-minute discussion about five services your organization cannot comfortably operate without.

Why a vendor’s problem becomes your business problem

Consider a typical firm in Ottawa, Gatineau or elsewhere in Canada. Microsoft 365 or Google Workspace supports communication. Separate providers handle accounting, payroll, customer relationships, payment processing, document signing and scheduling. A managed service provider manages access, devices or backups.

These services can make a small team more capable. They also create dependencies that a firewall or a well-maintained laptop cannot remove.

A service may become unavailable because of a technical failure, a configuration change, a cyber incident or a protective shutdown. A provider can also suffer a data breach while continuing to operate. Treat availability and the protection of information as separate questions: a working application does not prove that its data is unaffected.

The practical consequence depends on the business process. A payroll interruption close to a submission deadline matters differently from a reporting tool being unavailable for an afternoon. Begin with the work and its deadlines, then identify the technology supporting it.

Recent context: two different dependency risks

On April 11, 2026, Canada Life notified the Government of Canada about a cyber incident, according to Treasury Board briefing material. That is a notification date, not a confirmed intrusion date. Canada Life’s initial statement said regular operations continued. Its subsequent update says it informed affected individuals and relevant advisors and plan sponsors. This Canadian example concerns information and communication, not a claimed service outage.

A separate availability example is the October 19–20, 2025 AWS disruption. Amazon attributed the initial problem to DNS resolution in US-EAST-1 and reported full service recovery on October 20. This was a US-region event, not evidence that every Canadian customer or Canadian cloud region was affected.

The planning lesson is to ask two questions: what will we do if a provider cannot deliver the service, and what will we do if it reports that information was exposed? The answers may involve different people and different decisions.

The dependencies that do not appear on your IT list

Start with the subscription list, but do not stop there. Ask finance about recurring payments and department managers about tools purchased directly. A project team’s file-sharing account or an office manager’s scheduling subscription may have become essential without a formal review. This is often called shadow IT.

Then look beneath the vendor names. Two applications may depend on the same cloud provider. Your backup console and your production systems may use the same sign-in service. Several “alternatives” can therefore share one point of failure.

People and access create dependencies too. If one administrator is the only person who can open a support case, recover an account or approve an emergency purchase, that person’s availability becomes part of the recovery plan. Outsourced IT does not remove the need for an internal business owner.

Record which information the provider holds, whether you can export it, and what those exports actually contain. A spreadsheet of client names may help with calls; it will not recreate a document-management system, its permissions or its audit history.

A 30-minute exercise for your five critical services

Invite an executive, someone from operations or finance, and your IT lead or provider. Use a shared document and a timer. The goal is a useful first pass, with unknowns assigned for follow-up. Do not turn the meeting into a discussion of every subscription.

Minutes 0–5: choose five services

List the external technology services whose loss would most quickly affect safety, client commitments, cash flow or essential work. Include a backup or IT provider if it is necessary to restore another service. Choose actual services, not broad labels such as “the cloud.”

Minutes 5–15: complete the dependency table

Replace the illustrative entries below with your vendors and named internal owners. The suggested workarounds are prompts to validate, not instructions to improvise during an incident.

Example starting point — validate every workaround and time limit
Service / vendor	Business process	Data involved	Impact if unavailable	Workaround	Owner
Payroll provider	Pay employees	Pay and banking details	Missed processing cutoff	Pre-approved contingency with finance	Finance lead
Client-file platform	Deliver client work	Confidential records	Files inaccessible	Approved, current essential-file copies	Practice lead
Scheduling service	Coordinate appointments	Names and appointments	Bookings cannot be checked	Protected daily schedule and phone process	Office manager
Accounting platform	Invoice and collect	Balances and transactions	Billing backlog	Controlled invoice log for later reconciliation	Controller
Email / collaboration	Coordinate response	Messages and contacts	Team cannot coordinate	Verified phone tree	Operations lead

For each row, add maximum acceptable downtime, the provider’s support and escalation contacts, available backups or alternatives, and who needs to be informed. Keep contact details accessible outside the affected service. Never put passwords or recovery codes in this general-purpose worksheet.

Distinguish your business limit from a vendor’s promised restoration time. Also record how much recent work you could afford to lose. Being able to restart tomorrow is different from being able to recover yesterday’s transactions.

Minutes 15–23: test four durations

One hour: What pauses, and who confirms the incident?
One day: Which deadlines or client commitments are at risk?
Three days: Can the workaround handle the growing backlog?
One week: What must stop, move elsewhere or be renegotiated?

Change the timing once: imagine the outage happens on payroll day, during a closing, or before a major delivery. A service’s importance can change with the calendar. If a workaround requires the same unavailable login, mark it as unproven.

Minutes 23–27: select the three biggest gaps

Prioritize gaps by business consequence and urgency. “No way to reach staff without email” is actionable. “Improve cybersecurity” is not. Other useful findings include an inaccessible emergency contact list, an untested export, or a recovery estimate longer than the business can tolerate.

Minutes 27–30: assign the next action

Give each gap an owner, a due date and evidence of completion. For example: “Operations will test the phone tree with three team leads by Friday and record the results.” Schedule a follow-up to confirm that the three actions worked.

The Cyber Centre’s business-continuity planning guidance provides a broader framework. This short exercise starts the conversation; it does not replace a complete continuity plan.

Five controls worth prioritizing

1. Maintain a vendor inventory with business owners

Connect each critical service to its process, information, renewal date and decision-maker. Review the list when a department adopts a new tool or changes providers. This makes it easier to spot concentration risk and decide where a stronger recovery arrangement is worth the cost.

2. Protect administrator access

Use MFA, preferably phishing-resistant options where supported, and limit administrator privileges. Identify a trained backup administrator and a controlled emergency-access process. Test that process without broadly disabling protection. These measures reduce access risk; MFA alone does not keep a vendor’s service online.

3. Verify that recovery works outside production

Ask which data is backed up, how it is protected from deletion or alteration, and whether recovery depends on the same accounts or provider. Consider isolated or immutable copies where appropriate. Test a small restoration and check that the recovered information is usable.

A backup is not a replacement application. Record the tools, permissions, time and people needed to use it. Measure actual recovery against your business limit rather than relying on a successful backup notification.

4. Prepare communications and manual procedures

Choose an alternate communication channel and keep a protected copy of essential contacts. Define who can activate the plan, approve temporary spending and speak to clients. Prepare a short message stating what is affected, what people should do and when the next update will arrive.

Keep manual records secure and limit the information collected. Plan how to reconcile them when service returns so invoices, appointments or payments are not duplicated.

5. Agree on escalation, then practise it

Review contractual incident-notification terms, support coverage, data-return options and recovery commitments. Check with your insurance broker whether dependent business interruption is covered and which notification conditions apply. Coverage depends on the policy.

Run another tabletop exercise after a major change and on an agreed schedule. Track unresolved actions and retain the test record. The Cyber Centre’s baseline controls are a useful reference for the underlying security programme.

Ten questions for your technology provider

Which external systems support our most time-sensitive work?
Which providers hold our most sensitive information?
Do our critical applications share cloud, identity or network dependencies?
What can we still do if Microsoft 365, Google Workspace or our main SaaS platform is unavailable?
Who has administrator access, and who can act if that person is absent?
How will we receive and verify an incident notification outside normal email?
What do our contracts require the provider to tell us, and when?
Can we reach and restore backups if production access is lost?
What was actually demonstrated in the last recovery test?
Who has authority to activate our plan and approve client communications?

Ask for examples and evidence. “We have backups” is a starting point; the last test result, its limitations and the next corrective action are more useful.

The same issue looks different across industries

The following are planning scenarios, not reports of incidents at particular organizations.

Professional services: Law and accounting firms may lose access to client files or filing workflows. Engineering and architecture teams may be unable to retrieve approved drawings. Identify deadline-critical material and how to verify its current version.
Healthcare clinics: Scheduling and record systems affect different parts of care. A clinical lead should define safe downtime procedures and when appointments must be deferred; a printed schedule alone is not a clinical record.
Non-profits: A donor or case-management platform may hold the contacts needed to coordinate services. Keep essential continuity information protected and accessible to authorized staff.
Real estate, mortgage and insurance: Document portals and signing services can delay closings, applications or renewals. Establish approved alternatives and independently verify any changed payment instructions.
Logistics and transportation: Dispatch, routing and proof-of-delivery tools support daily commitments. Test a limited manual dispatch process and identify the volume at which it becomes unsafe or unmanageable.
Construction: Site teams may depend on cloud drawings, scheduling and subcontractor portals. Decide how to distribute the latest approved information and stop work when essential safety information cannot be verified.

Your checklist before the next disruption

Five critical services have named business owners.
Downtime limits reflect actual deadlines and business consequences.
Support contacts and response instructions are accessible during an outage.
Workarounds protect information and have been tried.
Three priority gaps have owners, due dates and a follow-up.

When an incident occurs, verify information through known provider channels. Preserve notices and decisions. Involve your privacy lead if personal information may be affected, so applicable reporting and notification requirements can be assessed. Do not assume an outage is a breach, or that the provider’s response completes your own responsibilities.

Turn dependency risk into practical priorities

Cyber resilience means understanding what your business relies on and preparing to continue essential work when a dependency fails. You cannot prevent every incident. You can make the next decision easier by agreeing on owners, limits and workable alternatives today.

Not sure which technology dependencies could stop your operations? InnoAxis Solutions Inc. helps Canadian organizations identify cybersecurity, cloud and operational risks and turn them into practical priorities.

Explore the Secure Foundation approach, or book a short conversation about your environment, recovery priorities and next steps.

Book a short conversation

GPT-6 Astra for Construction: What to Secure Before AI Takes Action

Updated September 14, 2026

An employee asks to connect an AI tool to your project folders so it can prepare the weekly status report.

The potential benefit is easy to understand: less time gathering information and more time managing the project.

But approving the request involves more than deciding whether the AI produces a good summary. Which folders will it access? Could it read another project’s confidential bid? Can it send the report, change a record or follow instructions embedded in a subcontractor’s document?

OpenAI released GPT-6 Astra on September 3, 2026. Its documentation describes a model built for complex work involving reasoning, computer use, research and document creation. That makes it relevant to businesses considering more capable administrative workflows. ^[1]

For construction leaders, the practical starting point is a defined workflow – not unrestricted access. Decide what AI may read, what it may change, who approves consequential actions and how you will judge the result.

What changes when AI can take action?

An AI assistant might draft a project update for an employee to review. An agentic workflow can also use connected tools to retrieve information or act in software. ^[2]

The distinction is not simply the model name. The surrounding product, tools, identity and execution environment determine what the system can actually do. OpenAI’s computer-use documentation, for example, describes an environment that executes the model’s requested actions; the model does not independently acquire access to a company’s systems. ^[2]

Nor did computer use begin with Astra. OpenAI identifies several supported capabilities as continuations of those available with the previous model generation. The important development is increasing capability – not the sudden disappearance of existing governance principles. ^[3]

Keep foundational security controls in place. Account management, secure configuration, security updates, backups and incident preparation remain relevant. The Canadian Centre for Cyber Security includes these practices in its baseline guidance for smaller organisations. ^[4]

The additional task is to apply appropriate boundaries to AI-enabled workflows.

Start with one project-reporting workflow

Consider a hypothetical 50-person construction company testing AI-assisted weekly reporting. This is an illustrative pilot design, not an InnoAxis customer case study or a claim of proven results.

The proposed workflow is deliberately narrow: read approved records for one project, identify outstanding items and prepare a draft status report.

Decision	Proposed pilot boundary
Information available	A designated project folder containing approved documents and reports
Output	A draft that identifies its source documents, versions and unresolved questions
Human responsibility	A project manager checks accuracy and completeness before distribution
Excluded actions	Approving payments, changing supplier banking information, modifying contracts or drawings, granting access, or sending external communications

Before selecting the tool, decide what a successful report must contain. Does it identify the current document version? Distinguish a proposed change from an approved change? Flag missing information instead of filling the gap with an assumption?

Those requirements become the pilot’s acceptance criteria.

This approach also makes it easier to evaluate alternatives. Compare an improved manual process, conventional workflow automation and AI-assisted reporting against the same criteria: quality, total effort, cost and consequence of error.

The most capable model is not automatically the best business choice.

Review the identity – not just the employee's access

Do not assume that every AI integration operates with exactly the same permissions as the employee using it.

Microsoft Graph illustrates the distinction. A delegated integration acts on behalf of a signed-in user within the permissions granted to the application and that user. An application-permission integration can operate through its own identity without a signed-in user. ^[5]

Ask the person implementing the workflow to identify the account or application involved, the documents it can access and the actions it can perform.

For the reporting pilot, access to unrelated HR files or another project’s tender documents is unnecessary. Resolve those boundaries before connecting the agent – not after the first useful demonstration.

Review browser and desktop access as well as application connections. Because computer-use systems can operate through software interfaces, restricting API integrations alone is not a complete assessment of the available access paths. ^[2]

Treat external documents as information, not authority

A subcontractor document should inform a project report. It should not be able to redefine what the AI is authorised to do.

This matters because of prompt injection: malicious instructions embedded in material an AI processes, such as an email, document or web page. An attacker may try to redirect the system, obtain information or trigger an unintended action. OWASP identifies these external-content attacks as a security concern for AI applications. ^[6]

For example, a malicious attachment could attempt to persuade an agent to send project information to an unrelated recipient. That example is hypothetical, but the underlying attack mechanism is documented. ^[6]

A prompt saying “never share confidential information” is useful guidance. It is not a substitute for technical restrictions.

Enforce permitted actions in the application or connected system. A reporting agent that does not need to send email should not receive a general-purpose sending tool. A consequential operation should require approval outside the model’s own judgment. OWASP specifically recommends downstream authorisation and human approval for high-impact actions. ^[7]

Also control who receives the output. A workflow can expose information through its report even when it cannot modify the original files.

Separate training, retention and data location

“Are we using an enterprise account?” is not a complete data-handling assessment.

OpenAI says it does not train on inputs or outputs from ChatGPT Business, ChatGPT Enterprise or its API by default. Individual-service content may be used for training, with opt-out controls and stated exceptions. Consequently, neither “every personal account trains on company data” nor “only Enterprise avoids training” is accurate. ^[8]

Non-training does not mean zero retention. OpenAI’s API documentation describes separate retention arrangements, and Zero Data Retention requires approval and has limitations involving supported endpoints and capabilities. ^[9]

Data location is another question. OpenAI distinguishes storage at rest from processing location and limits certain residency options to eligible customers. A storage-location commitment should not be treated as a promise that every part of a workflow occurs in the same country. ^[10]

Before providing confidential information, document the applicable training terms, retention settings, storage and processing arrangements, and any third-party services involved.

For personal information, Canadian privacy regulators emphasise that generative AI remains subject to existing privacy frameworks. Their guidance addresses legal authority, appropriate purposes, safeguards and accountability. The obligations for a particular organisation depend on its circumstances; purchasing a subscription does not resolve that assessment. ^[11]

Make human review part of the business case

A fast draft is not the same as a completed business process.

For the pilot, measure the time required to prepare inputs, review the report, correct errors and handle exceptions. Include software and implementation costs. Record whether the output misses important items or creates additional work for project managers.

Set the acceptance criteria before the pilot, rather than adjusting them to justify the tool afterward.

A useful decision rule is:

Expand only when the workflow demonstrates acceptable quality and a defensible benefit after review, correction and operating costs.

Risk management should continue after the first successful test. NIST’s Generative AI Profile supports incorporating trustworthiness into the design, use and evaluation of AI systems rather than treating evaluation as a one-time activity. ^[12]

If the review burden outweighs the benefit, simplify the workflow, reduce its scope or choose another approach.

A practical first 90 days

The following is a planning sequence, not a guarantee that a workflow will be ready for wider deployment within 90 days.

Days 1-30: establish the boundaries

Identify the AI tools already being used and the business problems employees are trying to solve. Give staff a clear route to request an approved tool rather than relying only on prohibitions.

Select one workflow and assign a business owner. Review the relevant account terms and information-handling requirements. Correct the permissions for the data being connected, define permitted outputs and document excluded actions.

Use synthetic or otherwise appropriately minimised information when real personal information is unnecessary. Canadian privacy regulators recommend considering these alternatives and evaluating whether a proposed use is necessary and proportionate. ^[11]

Organisation-wide document cleanup may continue separately. What should not wait is control over the pilot’s own information and access.

Days 31-60: test normal work and failure conditions

Run a limited pilot with a small group.

Include missing documents, conflicting versions, incorrect inputs and attempts to manipulate the workflow. Test whether approval requirements and access restrictions hold when the task cannot be completed as requested.

Keep useful records of actions, approvals and errors, while protecting sensitive information in those records. Establish a way to stop the workflow and revoke its access. OWASP’s agent-security guidance recommends adversarial testing, monitoring, bounded execution and careful handling of sensitive logs. ^[13]

Days 61-90: decide whether expansion is justified

Compare the results with the original process and the acceptance criteria.

Can the owner explain what information was used? Are outputs sufficiently reliable? Is review effort proportionate? Can failures be investigated and the workflow stopped?

Expand only where the results justify it. Otherwise, correct the design, narrow the task or discontinue the pilot.

The objective is controlled delegation

A useful AI workflow should have a clear purpose, a defined information boundary, limited authority and an accountable owner.

For a construction business, the first success may be a better weekly reporting process – not an autonomous system connected to every project and financial application.

Start with a workflow whose value can be measured and whose mistakes can be detected before they create a business commitment.

Establish your security baseline before expanding AI access

InnoAxis’s Secure Foundation offering reviews cloud posture, identity, data exposure and governance, then establishes a prioritised roadmap. InnoAxis works alongside an existing IT provider rather than assuming it must replace that team. ^[14]

Book a fit call to discuss the security baseline for your first AI-enabled workflow.

Frequently asked questions

Does GPT-6 Astra automatically gain access to company files?

No. Access depends on the product, connected tools, accounts and permissions involved. The model’s supported capabilities are not, by themselves, permission to access a company’s environment. ^[15]

Is a business subscription enough to make an AI workflow secure?

No. A subscription may provide useful privacy and administrative controls, but those controls vary by offering. The organisation still needs to assess the workflow’s data, permissions, approvals and operating arrangements. ^[10]

What does Astra's "Critical" cybersecurity classification mean?

OpenAI says Astra reached the Critical cybersecurity capability threshold under its Preparedness Framework. It describes assessed capability and the associated need for safeguards. It is not a statement that every use is unsafe, nor a guarantee that a particular deployment is safe. ^[16]