Frequently Asked Questions

CiBRAI is an Australian agentic AI cybersecurity operating platform that brings security monitoring, threat intelligence, investigation, response workflows and reporting into one operational environment. It combines a SIEM and data lake with case management, AI assistance and connected security tools to help organisations understand threats and act on them.

CiBRAI serves security teams, business leaders, government agencies and managed service providers. Its purpose is to reduce the manual effort between finding a security signal, investigating it, authorising a response and explaining the outcome.

A cybersecurity operating platform brings the work of security operations together. It connects telemetry, asset and identity context, threat intelligence, investigations, response actions and evidence so teams can manage an incident through a coherent workflow.

For CiBRAI, the operating platform concept means carrying useful context through detection, investigation, response and management. Analysts can work with a connected incident record, while executives and assurance teams receive information suited to their responsibilities.

An organisation may already have capable security products and still spend substantial time moving information between them. Analysts often need to correlate alerts, gather asset details, check intelligence, update tickets and reconstruct reports manually.

CiBRAI addresses that operational workload by connecting information and workflows. The expected benefits are clearer prioritisation, less repeated investigation effort and more consistent response records. The value depends on the quality of the connected data and how the organisation uses the platform.

CiBRAI combines capabilities across these areas. Security information and event management, or SIEM, provides telemetry and alert context. Security orchestration, automation and response, or SOAR, connects response activities. Cyber threat intelligence, or CTI, adds information about indicators and adversary behaviour. AI assistants help interpret evidence and progress operational tasks.

These capabilities sit within the wider CiBRAI operating platform. Their depth, automation level and integration scope depend on the selected subscription and deployment.

No. Cybersecurity Operating System describes CiBRAI’s role in coordinating security operations. It does not mean replacing the operating systems on your computers or servers.

CiBRAI works with supported endpoints, infrastructure and security products. Your organisation continues to use its existing operating systems and business applications while CiBRAI brings relevant monitoring, investigation and response activities together.

CiBRAI is designed for organisations that need stronger security operations and clearer oversight. This includes smaller businesses building their security capability, enterprises improving an existing SOC, government agencies with specific assurance requirements and managed security service providers supporting multiple customers.

Analysts use the platform for investigations and response. CISOs and IT leaders use it to understand priorities and operational performance. Boards and executives use its reporting to understand incidents, exposure and decisions requiring attention.

Consider CiBRAI when your priorities include a unified operating workflow, agentic AI with human oversight, integration with existing security investments and Australian deployment options. The platform connects technical investigation with response records and reporting, which is particularly relevant when operational security and assurance need to work together.

The strongest reason to choose CiBRAI is demonstrated fit for your environment. A useful evaluation should test your actual data sources, decision processes, deployment requirements and cost assumptions.

Yes. CiBRAI’s operating model connects security events, threat context, AI-assisted analysis, cases, response workflows and reporting. An investigation can retain its evidence and context as it moves towards containment and closure.

The selected plan determines which functions are included and how far automation extends. Enterprise deployments can include custom integrations and workflows. The agreed scope should identify the platform capabilities, external products and service responsibilities involved in each operational use case.

It means an analyst can bring related security activity into a case, review the supporting context, use AI assistance, follow an authorised response workflow and retain the resulting evidence for reporting. For example, a suspicious identity event can be considered alongside connected endpoint activity and relevant threat intelligence.

The benefit is continuity across the investigation. The precise workflow depends on the connected sources, available permissions and enabled response actions.

Core self-service plans include live SIEM alerts, case and incident management, core agentic AI assistance, guided investigation, threat intelligence context and an isolated customer workspace. Higher plans add functions such as richer enrichment, reporting and response automation.

External integrations provide additional telemetry and access to actions in other products. Custom connectors, private feeds and specialised workflows may require separate scoping. The current plan comparison and your order form define the final inclusions.

CiBRAI can bring together relevant information from endpoints, servers, identity systems, cloud environments, networks and business applications. Its monitoring scope can also include email, vulnerability information, websites and other internet-facing services through suitable agents, logs or integrations.

Coverage depends on what each source exposes and what has been connected. A system being listed in an asset inventory does not necessarily mean that its security events, configuration and response controls are all available to the platform.

Yes. CiBRAI’s self-service offering supports agents for Windows, macOS and Linux machines. Agents provide endpoint and server visibility within the supported configuration.

Before rollout, confirm operating system versions, required privileges, network access, deployment methods and any compatibility constraints. An initial group of representative machines helps validate agent behaviour and telemetry before extending coverage across the organisation.

CiBRAI is designed for environments that use multiple vendors. Integration options include Microsoft Defender, SentinelOne, CrowdStrike, Microsoft Sentinel, Splunk, Entra ID, Okta and common network security platforms.

Compatibility must be checked against the exact product, version, licence and use case. Receiving alerts, retrieving additional evidence and executing a response are different integration capabilities. Confirm each required capability during scoping rather than assuming that a named integration supports every action.

CiBRAI can augment an existing environment and may support selective consolidation where its capabilities satisfy the relevant requirements. It also provides its own SIEM and data-lake capabilities.

A replacement decision should account for detection coverage, retention, historical searches, integrations, specialist controls, migration effort and service obligations. Existing tools should be retired only after the replacement scope has been validated. A phased adoption allows your organisation to test value while maintaining the controls it currently relies on.

CiBRAI is designed to work alongside endpoint protection and other security controls. Its monitoring, correlation, investigation and response workflows can use information from those products.

Installing CiBRAI does not, by itself, justify removing antivirus or endpoint detection and response software. Any proposed replacement requires a specific assessment of prevention, detection, isolation, recovery and support requirements for the endpoints concerned.

CiBRAI can bring relevant vulnerability and asset information into an investigation or remediation workflow when suitable data sources are connected. Teams can use that context to prioritise exposed systems, track actions and retain closure evidence.

Patch deployment and configuration changes depend on the connected management tools, enabled workflows and approved permissions. The agreed implementation should distinguish identifying an issue, assigning treatment, executing a change and verifying that the change worked.

CiBRAI supports operational investigation through cases, timelines, linked evidence, endpoint and log context, indicator enrichment, notes and reporting. These functions help analysts reconstruct activity and document their findings.

Specialist forensic acquisition, formal legal chain-of-custody services and expert witness work are separate requirements. If an investigation may involve litigation, law enforcement or regulatory evidence, agree the preservation procedures and specialist support before relying on a standard operational workflow.

Agentic AI uses AI-driven workflows to progress tasks across available information and tools. In security operations, this can involve gathering evidence, enriching indicators, relating events, explaining findings and proposing next steps.

Useful agentic behaviour operates within defined permissions and an agreed purpose. In CiBRAI, AI assistance supports the investigation and response process, with human approval and an audit trail forming part of the operating model.

CiBRAI AI assistants help explain alerts, group related activity, enrich investigations and produce summaries. Depending on the selected plan and configured workflow, they can support scheduled reviews, threat context, prioritisation and recommendations for response.

The assistants work with the evidence and permissions available in the customer environment. Their usefulness increases when telemetry, asset information and operating procedures are well maintained. Custom AI workflows can be scoped for enterprise requirements.

Automation operates within the permissions and workflows agreed for the deployment. CiBRAI’s response model holds high-impact actions for an authorised human decision and records the activity in the audit trail.

During onboarding, define which activities may run automatically, which need review and which are prohibited. For actions such as isolating a device or revoking a session, confirm the approval path, business impact and recovery procedure before enabling the workflow.

CiBRAI combines AI assistance with approval workflows, role-based access and recorded actions. The organisation remains responsible for setting decision authority, assigning operational roles and determining acceptable automation.

An effective implementation makes the approval process explicit: who may authorise an action, what evidence they need and how the decision is retained. Access to a tool should reflect the operator’s or agent’s authorised role and the sensitivity of the affected system.

Yes. AI-generated findings and summaries can be incomplete or incorrect, particularly when evidence is missing, ambiguous or misleading. Analysts should verify material conclusions against the underlying records before taking consequential action.

CiBRAI’s use of cases, supporting context and human decision points helps place AI output within an operational review process. Evaluation should test both useful outputs and failure cases, including missing telemetry, incorrect enrichment and attempted manipulation of material being analysed.

Assess the workflow’s access, evidence sources, permitted actions and failure behaviour. Relevant checks include protection of credentials, treatment of untrusted input, separation of customer data, human approval, action logging and the ability to stop a workflow.

For CiBRAI, these requirements should be included in deployment design and demonstrated for the selected configuration. Ask how recommendations are checked and how a failed or inappropriate action would be contained and recovered.

CiBRAI is designed to help analysts spend less time collecting and reconciling information. AI assistance and response workflows can reduce repetitive work so people can focus on investigation quality, business impact and decisions requiring judgement.

Staffing decisions depend on coverage requirements, incident workload, risk appetite and the operating model. Continuous software availability should not be interpreted as a promise that every incident will be investigated by a human at every hour.

Measure the work performed and the quality of the result. Useful measures include analyst time per comparable case, time to a justified decision, task completion, correction rates, escalations and failed response attempts.

Compare a defined baseline with the same types of work after deployment. Faster processing is valuable when detection quality, evidence quality and response safety remain acceptable. Review results over a meaningful period rather than judging the platform from a single demonstration.

CiBRAI is an Australian cybersecurity platform with Australian-hosted deployment options. CiBRAI operates infrastructure at Equinix SY4 in Sydney, and self-service subscriptions are designed around isolated Australian-hosted customer tenancies.

Enterprise customers can discuss dedicated, on-premises and other scoped deployment arrangements. Your agreement should identify the locations used for storage, processing, backup and support, together with any relevant subprocessors.

Sovereign AI concerns control over the data, processing and administration used to operate AI. For a CiBRAI deployment, that means examining where telemetry and prompts are processed, where results are retained, who can administer the environment and which external services are involved.

Australian hosting is one part of that assessment. The complete design must also address model inference, remote access, operational responsibilities and contractual controls relevant to the organisation’s requirements.

CiBRAI offers enterprise deployment options that can be scoped for dedicated environments, on-premises infrastructure and air-gapped requirements. The design depends on the required capabilities, data volumes, hardware, resilience and permitted connectivity.

An isolated environment needs an agreed method for software updates, intelligence imports, model maintenance and support. Confirm which functions remain available without external connectivity and how operational evidence will be retained and exported.

The answer depends on the model and deployment configuration. CiBRAI supports deployment discussions that address local or private processing and the use of external AI services where appropriate.

Before deployment, agree which data classes may be processed by each model, where inference occurs and whether any information crosses the defined environment boundary. Where external processing is prohibited, that restriction must be reflected in the selected architecture and enabled workflows.

Training use must be addressed explicitly in the data-processing terms for your deployment and any model providers involved. Using information to answer an operational query is different from retaining it for model training or service improvement.

Ask for the applicable position on prompts, telemetry, outputs, retention and provider reuse before enabling an AI service. Any restriction on secondary use should be captured in the agreement and matched by the selected configuration.

CiBRAI’s self-service offering uses isolated customer workspaces. Security controls include tenant separation, encryption, role-based access and access logging, with dedicated arrangements available for scoped enterprise requirements.

The appropriate controls depend on the service model. Your design should identify administrative roles, service-provider access, authentication requirements and the boundaries between customers. Dedicated tenancy, dedicated infrastructure and on-premises deployment are different arrangements and should be specified clearly.

Retention, backup, recovery and export requirements should be agreed for the chosen plan and deployment. Specify how long raw telemetry, cases, attachments, AI outputs and audit records must remain available, including any archival or investigation-hold requirements.

Before signing, confirm export formats, retrieval arrangements, deletion procedures, recovery objectives and any associated costs. A clear exit plan helps preserve the evidence and operational records your organisation needs if its service arrangements change.

CiBRAI is designed to support government security operations through controlled deployment options, investigations, response workflows and structured reporting. It can be considered by councils, state bodies and Commonwealth agencies according to their particular requirements.

Suitability must be assessed against the intended information, system boundary and operating environment. Government deployment discussions should cover private-cloud or dedicated requirements, administrative access, assurance evidence, data handling and the agency’s authorisation process.

No. A platform’s Australian location or security features do not, by themselves, establish approval to process classified information. Approval depends on the specific system, configuration, controls, assessment and authorising organisation.

Discuss the intended classification and handling requirements before sharing data or selecting a deployment. Any claim about an assessment or approval should identify its scope and the environment to which it applies.

CiBRAI can contribute operational evidence to a continuous compliance programme through monitoring information, incident records, response approvals, remediation activity and reporting. With the relevant sources connected, teams can use this evidence to identify changes and investigate whether controls continue to operate as intended.

The wider programme still needs control owners, assessment criteria, exception handling and review. Evidence collected by the platform should be mapped to specific requirements and checked for coverage, freshness and reliability.

Yes. CiBRAI offers Essential Eight reporting in relevant plans and can support an uplift programme with connected technical evidence and remediation tracking. The exact coverage depends on the enabled capabilities and available source data.

Achieving a maturity level requires implementing and assessing the applicable requirements across all eight mitigation strategies. A dashboard or report does not establish Maturity Level Three. Patching, access controls, application control and backup practices still need to operate effectively across the assessed scope.

CiBRAI can support relevant operational activities such as monitoring, incident handling, access oversight and evidence collection. Its records and reports can contribute to an information security management system and to assurance activities mapped to applicable ISM controls or PSPF requirements.

The organisation remains responsible for governance, policy, risk treatment, control implementation and assurance. A technical platform supports these obligations within its agreed scope; it cannot independently satisfy the full management system or policy framework.

Assessment status must be established for the specific legal entity, service and deployment being purchased. Ask the CiBRAI team for current certificates, attestation reports or assessment information applicable to your proposed service, including scope, dates and any limitations.

Terms such as ISO 27001 aligned or SOC 2 ready describe preparation or alignment and should not be read as a completed independent assessment. A hosting provider’s credentials also do not automatically extend to every application or customer configuration hosted there.

No. An IRAP assessment provides assurance information about a defined system and its implementation of relevant controls. The assessment scope and findings need to be considered by the organisation making the authorisation and risk decision.

For a CiBRAI deployment, establish the proposed system boundary, assessment needs and responsibilities early. Changes to architecture, processing locations or service arrangements may affect the assurance work required.

CiBRAI supports executive summaries, incident reporting and operational audit trails. These can help explain what occurred, which assets were involved, what action was authorised and what remains unresolved.

Reports should be reviewed for the intended audience and reconciled to the supporting evidence. Boards need a clear account of business exposure and decisions. Auditors need traceable records, appropriate scope and evidence of control operation. The reporting configuration should reflect both needs.

Yes. Gadget Access advisory and retained cybersecurity services can be scoped alongside CiBRAI. This can bring together leadership support, risk management, governance and technical security operations within an agreed engagement.

The scope should identify the responsibilities of your internal team, Gadget Access, CiBRAI and any other providers. Consulting, implementation, independent assessment and managed monitoring are distinct services, with their deliverables and commercial arrangements defined in the engagement.

Compare CiBRAI against the requirements that matter to your organisation: operational coverage, investigation quality, automation controls, integrations, deployment options, assurance and total cost. Include the exact product editions and services needed to deliver each outcome.

A comparison with Microsoft, Splunk, CrowdStrike, Palo Alto Networks or another provider should use current documentation and a practical evaluation. CiBRAI’s proposition is the connected operating workflow, supported by agentic AI and flexible deployment. Ask to see that proposition demonstrated against your requirements.

The best fit is the platform that demonstrates the required outcomes within your operational, security and budget constraints. Start with priority use cases, essential integrations, data-handling requirements and the decisions your team needs to make.

Then evaluate candidate platforms against the same scenarios and evidence standard. Include detection and investigation quality, human oversight, recovery from failed actions, implementation effort and ongoing operating costs. A broad feature list alone is insufficient to establish suitability.

CiBRAI is designed to reduce repeated manual effort by grouping related activity, adding context, supporting investigation and making response steps easier to follow. These capabilities can help analysts focus on cases requiring attention.

The improvement depends on the starting environment, data quality, integrations and operating procedures. Validate the effect using comparable incidents and a defined baseline, while checking that important activity has not been incorrectly suppressed or deprioritised.

No. A percentage in an illustrative scenario, a laboratory test and a measured customer deployment represents different kinds of evidence. None should be assumed to predict the same result in every environment.

When considering a CiBRAI performance claim, review its source, baseline, sample, product version, test conditions and measurement period. Representative scenarios explain how a workflow could improve; a customer-specific evaluation establishes whether that improvement is achieved in your environment.

Contact CiBRAI to discuss a demonstration and the evaluation options available for your environment. Ask for relevant technical material and any customer evidence that can be shared, subject to permission and confidentiality.

For a proof of concept, agree the scope, duration, data handling, commercial terms and success measures before starting. A useful evaluation follows selected cases from the original signal through investigation, response approval and reporting, including situations where the AI should defer to a person.

Measure whether the platform improves the work your team actually performs. Relevant measures include analyst minutes per case, time to triage, time to authorised containment, evidence completeness, action success, correction rates and reporting effort.

Record the baseline and deployment conditions so results can be interpreted fairly. Include detection quality and failure handling as well as speed. Where possible, compare similar incident types and report the variation in outcomes instead of relying on a single average.

Compare the total cost of the current operating model with the proposed CiBRAI model. Include software subscriptions, infrastructure, storage, retention, integrations, onboarding, training, support and managed services. Account for transition costs and any existing contracts that will continue.

Productivity savings should be based on measured work and realistic capacity changes. If analyst time is redirected to higher-value investigation, describe that benefit as additional capacity unless it produces an actual reduction in expenditure.

CiBRAI offers self-service plans and scoped enterprise arrangements. Pricing depends on the selected capability level, monitored estate and deployment requirements. Dedicated infrastructure, custom integrations, specialist services and additional capacity may affect the total cost.

Use the live Plans and Pricing page for current subscriptions and promotions. Confirm GST treatment, usage conditions, retention, support and any separate services at checkout or in the order form. Enterprise and government requirements are assessed through a scoping conversation.

For self-service subscriptions, a monitored machine is a supported Windows, macOS or Linux endpoint or server with an active CiBRAI agent connected to the customer tenant. Plan capacity is based on the applicable subscription limits.

Confirm the treatment of temporary, offline, retired and replacement machines under the current terms. Cloud services, network devices and other data sources may require different integration or capacity arrangements.

No. CiBRAI’s SME, Growth and Business offerings are primarily self-service platform subscriptions. Managed monitoring, co-managed operations, incident response and digital forensics services can be scoped separately.

Continuous platform operation and AI availability are different from continuous human monitoring. Your service agreement should specify monitoring hours, escalation arrangements, response responsibilities and the support available during a serious incident.

Onboarding starts by confirming the customer workspace, administrators, required coverage and operating responsibilities. The next steps include connecting initial machines or data sources, checking telemetry, validating alerts and establishing investigation and response workflows.

A small supported deployment may begin generating useful information quickly. Full operational readiness depends on estate size, integration complexity, security approvals and tuning. Enterprise deployments require an agreed implementation plan and acceptance criteria rather than a universal delivery promise.

Provide a summary of your organisation, monitored estate, operating systems, existing security tools and priority problems. It is also useful to identify deployment preferences, data-handling restrictions, retention requirements, compliance objectives and the teams responsible for response.

A description of two or three real workflows helps make the discussion practical. Share sensitive configuration details, customer information or incident evidence only through an agreed secure process.

Responsibility depends on the service agreement and your internal operating model. The platform provides information and workflows, while your organisation and any contracted service providers perform their agreed roles.

Before going live, identify who reviews alerts, approves containment, coordinates business recovery and communicates with executives or external parties. The escalation route should work during both normal hours and any separately agreed after-hours coverage.

CiBRAI offers a path from smaller subscriptions to broader capabilities and enterprise arrangements. Changes are subject to the current plans, capacity requirements and applicable agreement. Moving to dedicated infrastructure or an on-premises environment requires a separate migration assessment.

Review billing, notice periods, data export and deletion arrangements before committing. Self-service cancellation conditions and enterprise termination provisions are defined by their respective terms.

Yes. CiBRAI supports discussions with managed security service providers, resellers and co-managed service partners. The platform can help partners organise investigations, use AI assistance and provide customer reporting within their service offering.

The partner arrangement should define customer separation, delegated administration, licensing, onboarding, support and incident responsibilities. Branding, commercial terms and any additional integration requirements are agreed through the partner programme.

CiBRAI offers an AI hardware platform alongside its software deployment options. Hardware discussions can cover the computing resources needed for private or on-premises AI workloads and the environment in which they will operate.

Sizing should account for telemetry volumes, model requirements, concurrent workloads, storage, resilience, power and cooling. The hardware specification, software configuration and maintenance responsibilities should be agreed together so the resulting system supports the intended service.

Review the platform overview and current plans, then contact the CiBRAI team to discuss the outcomes you want to achieve. For a straightforward self-service requirement, the online onboarding route provides the starting point. For enterprise, government, private deployment or managed services, begin with a scoping conversation.

Bring your priority use cases and existing toolset. A focused discussion can establish the appropriate deployment, required integrations and evidence needed to evaluate CiBRAI for your organisation.