Enterprise web development built to survive security and change review
In an enterprise the hard part is rarely the engineering. It is producing evidence that satisfies security, privacy, procurement and change control without the project taking two years to deliver something ordinary.
What does High10 build for enterprise?
Enterprise web development is the delivery of large scale websites, portals and applications inside organisations with formal security, procurement and change governance. In Australia that means vendor risk assessment, Essential Eight aligned controls, Privacy Act obligations and, for regulated entities, APRA standards. It suits organisations where the approval path is longer and more consequential than the build itself.
Get a fixed written quote- Typical timeline
- 12 to 26 weeks
- What drives cost
- The number of integrations and how cooperative those systems are, identity and permission complexity, the assurance activities required.
- Best for
- Large corporates, regulated entities, universities, member organisations and national networks
- You own
- The code, the infrastructure, the data and every credential, from day one
- Built with
- SAML and OIDC identity, headless architecture, Australian data residency, documented environments
Your handover
Why enterprise digital projects stall
They rarely stall on code. They stall because nobody mapped the approval path before starting. A security architecture review was not booked, so it happens after the build and finds something structural. The privacy impact assessment was assumed to be a form and turns out to require a workshop. Procurement needs a vendor risk questionnaire completed with evidence, and the supplier has never seen one. The change advisory board meets fortnightly and the release window is monthly. Each of these is knowable in week one and expensive in week twenty.
- 01Solution and integration architecture documentation
- 02SSO integration with your identity provider and role mapping
- 03SCIM or equivalent user provisioning where lifecycle automation is needed
- 04Infrastructure as code with separated environments in Australian regions
- 05Completed vendor risk and security questionnaire evidence
- 06Penetration test coordination, remediation and retest
- WCAG 2.2 AA conformance verified by manual testing
- Change requests and release plans aligned to your governance cycle
- Runbooks, decision log and a formal handover to your internal team
The other pattern is estate sprawl
The other pattern is estate sprawl. A large organisation typically discovers it has dozens of microsites built by different agencies over a decade, several content systems, three analytics implementations that disagree, and a set of domains nobody can fully enumerate. Some of them still collect personal information. Some run software with unpatched dependencies. Consolidation is unglamorous work and it is usually the highest value thing an enterprise digital team can do, because the risk sitting in forgotten properties is real and it is attributable to the organisation, not to the agency that disappeared in 2019.
The assurance regime you have to satisfy in Australia
Enterprise procurement runs on evidence rather than assurance. Expect a vendor risk assessment covering your supplier's security practices, subcontracting, data handling and insurance, and expect questions framed against ISO 27001 or SOC 2 even where certification is not mandatory. The ACSC Essential Eight is the common baseline for control maturity in Australia, and its mitigation strategies translate directly into build requirements around patching, application control, multi factor authentication and administrative privilege. Penetration testing before go live, with a documented remediation cycle and a retest, should be scheduled at the start rather than squeezed in before launch.
The full list
Sector regimes sit on top. Banks, insurers and superannuation trustees are subject to APRA prudential standards, notably CPS 234 on information security and CPS 230 on operational risk management, which brings material service provider identification, contractual requirements and testing obligations that reach your delivery partner. Organisations operating assets in defined critical infrastructure sectors carry obligations under the Security of Critical Infrastructure Act 2018. Everyone handling personal information sits under the Privacy Act 1988, the Australian Privacy Principles and the Notifiable Data Breaches scheme, with cross border disclosure under APP 8 making data residency a design question rather than a hosting preference. Accessibility to WCAG 2.2 AA is a standard tender condition, and organisations working with government inherit expectations from the Digital Service Standard and, for classified data, IRAP assessed environments.
- Vendor risk questionnaires answered with evidence rather than assertions
- Essential Eight aligned patching, authentication and privilege controls
- Penetration test, remediation and retest scheduled in the project plan
- Australian data residency with cross border disclosure documented
- Privacy impact assessment inputs prepared alongside the design
- WCAG 2.2 AA verified by manual testing, not by an automated score
How the engagement runs
How an enterprise engagement runs
We work in fortnightly increments with a named delivery lead and a written decision log, because in a large organisation the cost of an undocumented verbal agreement is measured in months. Environments are separated properly from the start, with infrastructure defined as code so a rebuild is a script rather than an archaeology exercise.
- 01Map the approval pathSecurity, privacy, procurement, change and accessibility, with a named owner for each
- 02Discovery and architectureIntegrations, identity model, data flows and residency decided and documented
- 03Estate audit where relevantEnumerate existing properties, domains and data collection points
- 04Stage 4Build in increments with infrastructure as code, automated testing and a maintained decision log
- 05Stage 5Security testing and remediation, then retest, scheduled well before the release window
- 06Stage 6User acceptance and accessibility verification with real assistive technology, not a scanner score
- 07Stage 7Release through your change process, then a supported hypercare period and a formal handover to your team
Two decisions on your side that keep the project moving
We also plan for the handover from the first week rather than the last. Enterprise platforms outlive the agencies that build them, and a platform your internal team cannot operate is a liability regardless of how well it was engineered.
Choose the right level
The governance artefacts and who has to sign them
We ask for the approval map in the first week and build the plan around it. Most delays are caused by an artefact nobody was asked to produce until it blocked a release, and every one of the items below has a queue in front of it.
Artefact
01
Solution and integration architecture
Who usually signs
Enterprise or solution architect
When it has to exist
Before build starts, not after the first sprint
02
Vendor risk and security questionnaire
Who usually signs
Security and procurement
When it has to exist
During contracting, with evidence attached
03
Privacy impact assessment inputs
Who usually signs
Privacy officer or legal
When it has to exist
Alongside design, wherever personal information is involved
04
Penetration test report and remediation
Who usually signs
Security operations
When it has to exist
Before go live, with a retest booked
05
Change request and release plan
Who usually signs
Change advisory board
When it has to exist
Submitted to fit the board's cycle, not the project's
06
Accessibility conformance statement
Who usually signs
Digital or communications lead
When it has to exist
Before launch and after any significant change
How we work this out during scoping
The table lists what enterprise clients typically need from us and who usually owns the decision. Your organisation will differ in the detail, but if you cannot name a person for each row, that is the first risk to address.
What we build at enterprise scale
Identity is usually the first serious piece. We integrate with the identity provider you already run, typically Microsoft Entra ID or Okta, using SAML 2.0 or OpenID Connect, with SCIM provisioning where user lifecycle needs to be automated and role mappings that survive a reorganisation. Getting this right removes an entire category of access risk and makes offboarding a solved problem rather than a quarterly audit finding.
The rest of the answer
Beyond that the work tends to be a platform rather than a website: a content architecture that lets business units publish without breaking governance, an integration layer that gives a stable interface over systems you cannot change, portals for members, partners or staff, and a design system that keeps forty teams visually consistent. Architecturally this is often headless CMS with API development and cloud applications running on infrastructure you own in Australian regions, with security work treated as part of delivery rather than as a gate at the end. Reporting usually lands in Power BI because that is what the rest of the organisation already uses.
When we are the wrong partner
If you need a supplier already on a specific procurement panel, or a partner who will place thirty people on site for two years, we are not that firm and we will tell you early rather than wasting your evaluation time. Large systems integrators exist for that shape of work and there are good reasons organisations use them.
The rest of the answer
We are also the wrong choice if the real problem is organisational rather than technical. If four business units each want a different platform because they do not agree on who owns the customer, a new build will encode that disagreement rather than resolve it, and the honest first step is digital consulting to settle it. And if your enterprise requirement is genuinely a set of well-defined internal tools rather than a platform, custom software scoped tightly will cost less and deliver sooner. Public sector organisations should read our government page, where procurement and the Digital Service Standard are covered directly.
Everything included
The handover checklist
The practical artefacts your team or your development partner receives when this phase is complete.
- Solution and integration architecture documentation
- SSO integration with your identity provider and role mapping
- SCIM or equivalent user provisioning where lifecycle automation is needed
- Infrastructure as code with separated environments in Australian regions
- Completed vendor risk and security questionnaire evidence
- Penetration test coordination, remediation and retest
- WCAG 2.2 AA conformance verified by manual testing
- Change requests and release plans aligned to your governance cycle
- Runbooks, decision log and a formal handover to your internal team
Not sure which level you need?
A 45 minute call, no cost, no obligation. You leave with a scope, an honest timeline and a fixed written quote.
Questions buyers usually ask
Frequently asked questions
Scope and timeline
How long does an enterprise platform project take?
Usually 12 to 26 weeks, and the governance path drives more of that than the engineering. Architecture review, security assessment, penetration testing and change board cycles all have queues. We map those in the first week and build the plan around real dates, which is why our timelines tend to look longer at proposal stage and hold better in delivery.
Can you work with our security and procurement processes?
Yes, and we expect to. We complete vendor risk questionnaires with evidence, work to Essential Eight aligned controls, support penetration testing and remediation, and provide the architecture and data flow documentation your reviewers need. We ask for the requirements in week one rather than week twenty, because that is where most enterprise delays originate.
Ownership and handover
Who owns the code and the infrastructure?
You do, from day one rather than at the end. The repository, the cloud accounts, the domains and every third party service are registered to your organisation, and we work as a collaborator you can remove. Infrastructure is defined as code and handed over with runbooks, so your internal team or another supplier can operate the platform without us.
What does support look like after launch?
We run a hypercare period immediately after release, then move to an agreed support arrangement with defined response and resolution targets, an escalation path and a named contact. Patching, dependency updates and security advisories are handled proactively rather than on request, and we report on them, because unpatched dependencies are the most common finding in enterprise audits.
Detail and edge cases
What drives the cost of an enterprise build?
The number of integrations and how cooperative those systems are, identity and permission complexity, the assurance activities required, how many content or portal audiences exist, and the release cadence your change process allows. We scope those in discovery and send a fixed written quote per phase, so budget approvals can be sought against defined stages rather than an open-ended engagement.
Do you handle SSO with Entra ID or Okta?
Yes. We integrate with enterprise identity providers using SAML 2.0 or OpenID Connect, and implement SCIM provisioning where user lifecycle automation is required. Role and group mappings are documented so they survive a reorganisation. We treat identity as a first phase item because retrofitting it into a finished application is materially more expensive than designing for it.
Related services
Get a fixed written quote for your enterprise project
Tell us what has to be approved before anything can go live, and which systems the platform must integrate with. We reply within one business day.