Managed Engineering
Your cloud, security and platform engineering function, run by North Ark.
We take ownership of defined parts of your environment and operate them continuously. You get the depth of a platform team without hiring one, and your internal team keeps the work that needs the business context.
- Microsoft Partner
- AZ-104 and AZ-305 certified engineers
- Senior engineers only
- Brisbane-based, working across Australia
What North Ark owns
Scope is written domain by domain, so it is always clear who is accountable for what. Typical domains:
- Cloud operations: Azure subscriptions, landing zone governance, Azure Policy, identity and access to the platform
- Security engineering: Entra ID and Conditional Access, Defender, Sentinel analytics and response playbooks, vulnerability remediation
- Platform and infrastructure: servers, virtualisation, Azure Local, networking, DNS, certificates and lifecycle
- Patching and change: scheduled, tested and reported, with change records that stand up to audit
- Backup, DR and resilience: restore tests that get run, recovery runbooks that are current
- Cost: allocation, right-sizing, reservations and waste removal, reviewed on a set cadence
- Automation: infrastructure as code, pipelines and runbooks for every repeatable task
The recurring ladder
You can start with one monthly service and add more as trust builds. Each step is scoped in writing and can run on its own.
- Add-ons: round-the-clock monitoring by our security operations centre, vulnerability management with findings closed with evidence, and an incident response retainer with response targets and a prepared playbook.
- Advisory retainer: a fractional CISO and a fractional principal architect for strategy, board reporting, design authority and vendor oversight.
- Managed Microsoft 365 and security: identity, Intune, Defender, Sentinel, Purview, licence reviews and a service desk for your users.
- Managed infrastructure: servers, virtualisation, storage, firewalls and network devices, with monitoring and patching, scoped by component.
- Managed Engineering: the full service described on this page, with North Ark owning the domains you choose across cloud, security, platform, resilience, cost and automation.
Who owns what
Before go-live we agree a responsibility matrix, domain by domain, and both sides sign it. This is a typical starting point. Yours will reflect the domains in scope and whoever else supports your environment.
- Cloud operations: North Ark runs subscriptions, landing zone governance and Azure Policy. Your team approves new workloads and owns the budget.
- Identity and access: North Ark engineers Entra ID, Conditional Access and privileged access. Your team approves who gets access to what. Your MSP handles password resets and joiner and leaver requests.
- Security engineering: North Ark builds and tunes Defender and Sentinel, and fixes what they find. Your team sets risk appetite and signs off exceptions. Our security operations centre monitors alerts around the clock.
- Patching and change: North Ark schedules, tests, applies and reports on patches for servers and endpoints. Your team approves change windows. Your MSP fields user reports after a change.
- Backup and resilience: North Ark runs the backup platform, restore tests and recovery runbooks. Your team sets recovery priorities for each system.
- Network and platform: North Ark runs firewalls, routing, DNS, certificates, virtualisation and Azure Local. Changes that affect a site or a third party are shared.
- Cost: shared. North Ark finds and makes the savings. Your team decides where the money goes.
- End-user support, devices and on-site work: your team or your MSP.
- Applications and vendors: your team, with North Ark engineering the platform underneath.
How it runs
- Onboarding: we take over the environment against an Infrastructure Review baseline, agree the domains in scope, and put monitoring, access and runbooks in place.
- Operations: alerts are triaged by the engineers who own the outcome. Incidents end in a root cause and a permanent fix, and the fix is captured as code or a runbook.
- Change: platform changes go through peer review and pipelines. Larger pieces of work are scoped as Transformation Engineering so the ongoing agreement stays predictable.
- Review: weekly, monthly and quarterly reviews with your team, each with a written output. The review cycle is set out below.
The review cycle
Three standing meetings, each with a written output, so you always know what changed, what is at risk and what comes next.
- Weekly operations review. 30 minutes with your infrastructure lead. Output: the weekly operations note, covering changes shipped, open incidents, next week's changes and anything blocked.
- Monthly service and risk review. 60 minutes with your Head of IT or Head of Infrastructure. Output: the monthly engineering report and an updated risk register.
- Quarterly architecture review. 90 minutes with your CIO or Head of Infrastructure. Output: the quarterly architecture pack, covering posture, cost trend, the improvement plan for the next quarter and the decisions we need from you.
What the monthly engineering report contains
- Changes shipped, each linked to the pull request in your repository
- Incidents, with root cause and the permanent fix
- Risk register: what was closed, what was added, what moved
- Patch compliance by system group
- Backup results and the latest restore tests
- Security posture against the controls we manage
- Cost movement and savings made
- Automation added this month
- Next month's planned work and the decisions needed from you
Severity and response
Every issue gets a severity when it is raised. Response targets for each level are written into your agreement, along with the after-hours arrangements.
- P1, critical: a business-critical service is down or a security incident is in progress, with no workaround. An engineer starts on it immediately and your nominated contact is kept updated until it is resolved.
- P2, major: a critical system is degraded or a significant group of users is affected, and a workaround exists.
- P3, minor: a fault with limited impact, such as one system component or a small number of users.
- P4, planned: requests, changes and improvements, scheduled through the weekly operations review.
After hours
P1 issues are covered after hours when your agreement includes it, by a named on-call engineer. Security alerts are watched around the clock by our security operations centre, which contains threats and hands the cause to North Ark engineers to fix.
The first 90 days
- Days 1 to 30, take over safely: named, least-privilege access set up; a baseline taken from your Infrastructure Review or an onboarding assessment; your repository set up in your tenant; monitoring connected; runbooks written for the highest-risk systems; responsibility matrix signed.
- Days 31 to 60, run it: domains handed over one at a time; the first patch cycle and first restore test run by North Ark; alerts tuned so they mean something; the first monthly engineering report.
- Days 61 to 90, improve it: the first fixes from the risk register shipped as code; the first quarterly architecture review; interim arrangements closed out; the responsibility matrix reviewed against how the first 90 days went.
Working alongside your MSP
Many of the organisations we work with keep an MSP for the service desk, devices and on-site support. That arrangement stays in place. North Ark takes the engineering domains in the responsibility matrix.
The handoffs are written down: which tickets your MSP escalates to us, how they reach us, and how we hand fixes back. We coordinate changes with your MSP so their team knows what is changing and when.
If you later move those services in-house or to another provider, the matrix is updated and the engineering side carries on unchanged.
Your team keeps the business context
Your people keep everything that depends on knowing the business: application owners, user-facing requests, priorities and budget. North Ark takes the specialist infrastructure and security work and hands your team the results, documentation and the ability to see exactly what changed.
Because escalations reach a senior engineer directly, your team stops being the last line of defence for problems that cross network, identity and platform boundaries.
Why it scales without a matching headcount
Every incident we resolve is turned into a diagnostic pattern. Every deployment becomes infrastructure as code. Repeated tasks become automation, and AI-assisted tooling handles triage, evidence gathering and drafting so engineers spend their time on decisions.
The result is that scope can grow without the operating cost growing at the same rate, and the environment becomes more consistent over time rather than more fragile.
Questions buyers ask
Can you take over an environment someone else built?
Yes. Onboarding starts with a baseline of what exists and how it is configured. We document it before we change it, and anything risky goes on the risk register to be fixed in order rather than all in the first week.
How is Managed Engineering priced?
A fixed monthly fee for the domains in scope, agreed for the term. Larger pieces of work are quoted separately as projects, so the monthly fee stays predictable. After-hours cover is its own line. We quote after a conversation about the domains you would hand over.
Is there a minimum term?
Twelve months. Onboarding either follows an Infrastructure Review or includes a one-off onboarding assessment.
We already have an MSP. Do we have to change?
No. Your MSP keeps the service desk, devices and on-site support, and the split is written into the responsibility matrix, including how work moves between us.
What happens if the engineer who knows our environment is away?
Every client has a lead engineer and a named backup engineer, and everything we build is in your repository as code, runbooks and documentation.
Who owns the code and documentation?
You do. It lives in a repository in your tenant from day one.
How do we end the arrangement?
With the notice period set in your agreement. Everything is already in your repository. We run a handover to your team or your next provider, then remove our access and confirm in writing.
Does our internal team lose work?
Your team keeps the work that depends on knowing the business: priorities, application owners, users and budget. They spend less time on escalations and on-call for infrastructure faults.
Start a conversation
Run the environment without building the team.
Tell us which domains you would hand over first.
Talk to an Engineer