Technology
The technology behind the service.
Microsoft Solutions Partner depth. Cisco and Meraki networking. Senior security tooling. Honest about what we run, why we run it, and what humans rather than tools do.
- Microsoft Solutions Partner
- Cisco Partner
- ISO 27001
- Great Place to Work — Asia Top 30
- ITIL
Tech is the floor, not the ceiling
Every IT services firm publishes a technology page. Most are vendor-logo grids stacked above a headline that uses the word "cutting-edge" somewhere. We won't do that.
Technology is the floor. The competence is in how it's run, by whom, with what runbook, against which auditor's expectations, and with what accountability when something fails. The platforms below are the floor we work from — production-proven across 180+ hearts and 15 countries, run by named engineers, mapped to the regulatory frameworks our customers actually answer to.
We are deliberate about what we run. We don't claim every emerging platform. We don't position vendors as the differentiator. The four categories below are the working stack — the one engineers run on Tuesdays, the one auditors see when they ask for evidence, the one your runbook maps to.
One Pratfall sentence we'd rather get out of the way up front, since it shows up in the security category below: we don't claim AI in security operations. Tools don't stop attacks. People do.
Category 1
Cloud & Platform
Microsoft Azure (primary) · Amazon Web Services (where customer estate requires) · Microsoft 365 (full suite) · Azure DevOps · Terraform · Azure Arc
Multi-cloud where it makes sense. Single-cloud where the customer's estate already lives there. Azure-first as our default for new mid-market engagements — for one specific reason: the regulatory weather.
Australian regulatory expectations (CPS 234 + CPS 230 in particular, plus Essential Eight ML2 uplift roadmaps, plus Privacy Act compliance) presume a control coverage that maps cleanly onto the Microsoft enterprise stack. Auditors and APRA reviewers have seen this stack before. Evidence packs produced against it are shorter, cleaner, and easier to defend.
AWS appears in our customer base where the customer's existing estate is AWS-anchored, where specific data-pipeline workloads benefit from AWS services not duplicated in Azure, or where the customer-side architecture decision predates our engagement. We don't migrate AWS to Azure for the sake of standardisation.
Microsoft 365 is the working productivity platform across most engagements: Exchange Online, Teams, SharePoint, OneDrive, Intune for endpoint, Defender for identity / endpoint / Office 365, Purview for compliance, Entra ID for identity. Tenant administration is documented; licence optimisation is a quarterly conversation.
Infrastructure-as-code is non-negotiable for environments we manage. Terraform is the default tooling layer for landing-zones and infrastructure provisioning. Azure Arc extends governance and policy to on-premise and multi-cloud surfaces where the customer estate is hybrid by design.
Platforms in scope
- Microsoft Azure
- AWS
- Microsoft 365
- Azure DevOps
- Terraform
- Azure Arc
- Exchange Online
- Defender
- Purview
- Entra ID
Category 2
Infrastructure & Networking
Cisco · Meraki (primary networking) · VMware · Hyper-V · Azure Site Recovery · SD-WAN where appropriate
The plumbing layer. Long-tenured. Repeatable runbooks. Regional partner availability when something breaks at 4am.
Cisco and Meraki together cover most of the mid-market network estate. The reason is mechanical, not romantic: long partner availability, mature local support, the runbook our engineers have built over years, the alignment with Microsoft 365 / Teams routing patterns most of our customers run. We carry deep Cisco partner credentials and active certification across the network engineering team.
VMware and Hyper-V appear where customer estates already run them. Migrations between virtualisation layers happen occasionally — we don't propose them unless the business case justifies it. Disaster recovery for cloud-anchored environments runs primarily on Azure Site Recovery; on-premise DR varies by customer posture.
SD-WAN is on the menu where the customer's branch / multi-site architecture justifies it. We don't oversell SD-WAN to single-site customers because the marketing said we should. The honest scoping bar applies here as it does everywhere.
Network monitoring and proactive alerting are baked in by default for managed engagements. Customers see the dashboards. Tickets fire to the service desk before users notice the impact, where the architecture allows.
Platforms in scope
- Cisco
- Meraki
- VMware
- Hyper-V
- Azure Site Recovery
- SD-WAN
Category 3
Cyber Security
SentinelOne (primary EDR) · Palo Alto Networks (next-gen firewall) · CrowdStrike (alternate EDR) · CyberArk (privileged access) · Imperva (web application firewall) · Microsoft Sentinel (SIEM)
We don't claim AI in security operations. Humans do this work.
Modern SIEM and EDR platforms include machine-learning-based detection at the platform layer. That's table stakes — every modern managed security firm runs platforms with ML components. We don't market it as "AI-augmented security operations" because doing so would falsely position the model as the accountability layer, when the accountability layer is human. Our security analysts are senior, named, CREST-certified where customers require it, and on the runbook for every incident.
The platform stack itself is deliberately conservative for managed security serving APRA-regulated FS, partnership-led law firms, and accreditation-supportive healthcare networks. Conservative meaning: production-tested, audit-defensible, and well-instrumented — not the newest entrants on the market.
SentinelOne is our primary EDR layer for new engagements. Strong autonomous detection-and-response with named human review of alerts. CrowdStrike appears in customer estates where the existing tooling investment is CrowdStrike-anchored.
Palo Alto Networks is the primary next-generation firewall layer. Strong inspection capability, mature integration with the broader security stack, and good evidence-pack alignment for regulated customers.
CyberArk for privileged access management on engagements where customer regulatory posture (CPS 234 in particular) demands evidence-grade PAM. Imperva WAF appears where the customer's web-application footprint and threat profile justify a managed WAF tier.
Microsoft Sentinel is the primary SIEM layer for Defence and Resilience tier customers. Ingestion is broad (Microsoft estate plus non-Microsoft sources via connector). Detection rules are tuned per customer over the first 90 days. Human review of detections is the accountability layer.
Where AI sits in this stack — honestly: ML-based detection lives in the platforms. Pattern-of-life baselines, anomaly detection, and false-positive reduction at the platform layer are reality, not differentiation. What we do not do is hand off incident write-up, customer notification, or accountability to a model. Our security analyst writes the post-incident review. Our security lead presents it to your Risk Committee. The model is plumbing, not the partner.
Platforms in scope
- SentinelOne
- Palo Alto Networks
- CrowdStrike
- CyberArk PAM
- Imperva WAF
- Microsoft Sentinel
Category 4
Operations & Insights
ServiceNow (ITSM) · Microsoft Intune (UEM) · PatchMyPC (third-party patching scale) · Azure Monitor · Power BI · Azure Automation
The instrumentation layer. The bit that makes the rest of the stack visible — to engineers, to the CSM, to the board, to the auditor.
ServiceNow is the primary ITIL-aligned IT service management platform. Tickets, change management, incident management, problem management, and service-catalogue all run from one source of truth. Customers get visibility into their own ticket queue and SLA position; named leads run the monthly review from the same data.
Microsoft Intune is the unified endpoint management layer for most engagements. Modern endpoint management — Autopilot enrolment, configuration profiles, compliance policies, application deployment, conditional access integration — replaces the legacy Group Policy + SCCM model that mid-market customers often arrive with.
PatchMyPC addresses the third-party application patching layer at scale. Most mid-market estates have 200+ third-party applications across the user population; manual patching is infeasible. PatchMyPC integrates with Intune and produces evidence-grade patch records for Essential Eight ML2 and CPS 234 review panels.
Azure Monitor + Power BI are the dashboards-and-reporting layer. Customer-facing SLA dashboards run on Power BI; technical-team operational dashboards run on Azure Monitor. The reporting cadence is monthly to the CSM, quarterly to the board, on-demand for customers under live regulatory or insurer review.
Azure Automation runs the runbook automation layer for repeatable operational work. The point isn't novelty; it's that the work runs whether the engineer is on holiday or not.
Platforms in scope
- ServiceNow
- Microsoft Intune
- PatchMyPC
- Azure Monitor
- Power BI
- Azure Automation
Why we picked these platforms — the criteria
Vendor selection is not romantic. The four-line filter we run a platform through:
- 01
Regulatory alignment
Does the platform produce evidence that maps cleanly to CPS 234, CPS 230, Essential Eight ML2, Privacy Act, or equivalent regional frameworks? Vendors with weak evidence support get a hard look.
- 02
Regional vendor presence
Local support hours, regional data residency where relevant, partner channel maturity. We've been burned by globally-acclaimed platforms with weak regional support.
- 03
Production-proven across our customer base
New platforms get evaluated on internal estates and pilot customers before they go into production for managed-services customers. Customers don't want to be the lab.
- 04
Repeatable by named engineers
The runbook our team has built — and can hand to a new engineer in the third week of onboarding — has to be solid. "Vendor magic" doesn't survive staff change.
What we don't claim, technologically
- We don't claim AI as a security differentiator. ML-based detection at the platform layer is table stakes. Human security analysts are the accountability layer.
- We don't claim every emerging platform. New entrants need to prove customer-fit and audit-defensibility before they go into production for managed-services customers.
- We don't sell platforms; we sell outcomes. The vendor partnerships are the floor, not the value driver.
- We don't run a follow-the-sun model. Named accountability sits on every engagement.
- We don't claim "AI security" as an advisory offering. AI-related advisory work lives at the parent (BISTEC Global), not on this brand. Strict separation, deliberately.
Partnerships and accreditations
Vendor partnerships
- Microsoft — Solutions Partner with active credentials across the engineering team
- Cisco — Partner with active certification on the network team
- Meraki — Authorised reseller and managed-services partner
- AWS — Partner where customer estate justifies; not the primary cloud focus
- SentinelOne — Authorised MSSP partner
- Palo Alto Networks — Partner credentials across firewall and secure-access layers
Accreditations
- ISO 27001 — Information Security Management System certification
- Great Place to Work — Asia Top 30 (parent BISTEC Global, audited annually)
- ITIL-aligned — service-desk methodology and ITSM platform alignment
- CREST-certified security analyst capability — where customers require it
- SOC 2 Type II — target Year 1 (publicly tracked progress; not yet held)
SOC 2 Type II is a multi-quarter audit cycle. We track our progress publicly and don't claim it before the audit completes.
Tools don't stop attacks. People do.
Twenty minutes on a discovery call. We'll listen first, look at your existing platform investments, and tell you what we'd run differently — and what we wouldn't touch.
or call (+61) 413 649 132