Home/Reference Architecture/Pattern 2 · Enterprise A

Pattern 2 · Enterprise A

Dedicated infrastructure, open only to your IP ranges

Your own VPC, database, evidence store and encryption key on AWS — still operated by Iron Fort, so you carry none of the run cost. The application is published, but the firewall admits only the addresses your organisation comes from.

Talk to an architect Download the diagram
Dedicated infrastructure, open only to your IP ranges — architecture diagram
Pattern 2 · Enterprise A · Dedicated Iron Fort infrastructure — Small and mid-sized enterprises PNG, 3200×2000

What this pattern is

One Iron Fort managed scanner worker runs inside that dedicated VPC, and it is the only component that reaches your systems. Everything it collects stays inside infrastructure dedicated to you, under a KMS key scoped to your tenancy alone.

Applies to Enterprise plans (SMB). Every pattern runs the same platform — the same frameworks, the same evidence model and the same reports. What changes is who holds the infrastructure and where evidence comes to rest.

Deployment
Single-tenant VPC on AWS, operated by Iron Fort
Regions
Your choice of AWS region, including Canadian residency
You operate
Nothing — you supply your egress IP ranges
Isolation
Physical — separate VPC, database, bucket and KMS key
Evidence at rest
Dedicated S3 bucket, encrypted with a customer-scoped KMS key
Sign-in
Microsoft or Google, with two-factor enforced
Access
Published endpoint behind a WAF that admits only your allowlisted IP ranges

From connection to evidence

We stand up your VPC

Dedicated subnets, a dedicated database and evidence bucket, and an AWS KMS key scoped to you alone. Data subnets have no route to the internet.

You give us your egress ranges

The WAF is configured to accept requests only from your office and VPN addresses. Everything else is refused at the edge, before it reaches the application.

Your team signs in

Through Microsoft or Google, with two-factor enforced. There is no local password path.

One worker collects

A single Iron Fort managed scanner worker runs inside the VPC and makes outbound read-only calls to your systems. Nothing inbound to your network is ever required.

How you would actually get here

Two plans, because they answer different questions and usually different people. Read them here, or take the PDF into your own planning.

Everything in Pattern 1, plus a dedicated environment we build for you and a firewall that only your addresses get through. The extra work is a networking conversation, and it is worth having early because it gates access for everyone.

Before you start

  • Your office and VPN egress IP ranges, confirmed by whoever owns the firewall.
  • A decision on region, if residency matters to you.
  • A Microsoft or Google account for each person who needs access.
1

Design and region

Together
  • Confirm the AWS region, including Canadian residency if that is a requirement you have to evidence.
  • Agree the encryption posture: a KMS key scoped to you alone, and who may administer it.
  • Collect your egress ranges. Get these from the network team, not from a spreadsheet — stale ranges are the most common cause of a day-one lockout.

Done whenRegion, key policy and allowlist are agreed in writing.

2

Build your environment

Iron Fort
  • We provision a dedicated VPC, a dedicated database and evidence bucket, and your KMS key.
  • Data subnets are created with no route to the internet.
  • The application is deployed behind a WAF configured to admit only your ranges.

Done whenA request from an allowlisted address succeeds; one from anywhere else is refused at the edge.

3

Access and sign-in

Together
  • Administrators sign in with Microsoft or Google, two-factor enforced. There is no local password path.
  • Test from every location your team actually works from, including home VPN egress.
  • Agree the change process for adding an address range later, so it does not become a ticket nobody owns.

Done whenEvery person who needs access has it, from every network they use.

4

Connect your systems

Together
  • The single managed scanner worker inside your VPC is the only component that reaches your systems.
  • Grant read-only credentials as in Pattern 1 — CloudFormation stack, app registration, service account, OAuth.
  • Confirm the worker's egress is outbound only; nothing inbound to your network is required.

Done whenEvery in-scope system returns data on a test collection.

5

Scope, collect, populate

Together
  • Record the organisation and its systems; install the framework and choose a profile.
  • Run the first collection and separate real gaps from scoping errors.
  • Bulk-upload existing policies and set review cycles.

Done whenA coverage figure exists and every required policy has an owner and a review date.

6

Reporting and trust

Together
  • Schedule the recurring reviews and tag them to the frameworks they satisfy.
  • Generate the assessor reports and read them before the assessor does.
  • Publish the trust page — it is public by design, and separate from the allowlisted application.

Done whenThe programme runs without anyone touching infrastructure.

Sequence, not schedule. Phases are ordered by dependency. Elapsed time depends on your change process and scope, so we do not guess at it — ask us and we will estimate against your specifics.

Same adoption path as the managed tier, with one addition: the allowlist is a live dependency. If your network changes and nobody tells us, people lose access on a Monday morning and blame the platform.

1

Wire the allowlist into your change process

You
  • Add "notify Iron Fort" to whatever process changes office or VPN egress addresses.
  • Name a second person who can raise that change, so it does not depend on one calendar.
  • Test access from a new location before you need it, not after.

Done whenA network change has been made and access survived it.

2

Give it an owner

You
  • Name one person accountable for the programme. Not a committee — programmes with three owners have none.
  • Name control owners per domain: access, change, backup, vendor, training. These are the people who will be asked for evidence.
  • Agree who signs off a policy and who accepts a risk. Write both down before you need them.

Done whenEvery control set in scope has a named owner who knows they own it.

3

Pilot on one framework

Together
  • Pick the framework you are actually being asked for. Adding a second later reuses this work; starting with two doubles the argument about scope.
  • Run a gap analysis and accept that the first number will be low. It is a baseline, not a grade.
  • Work the top ten gaps only. Breadth comes after the team believes the tool.

Done whenOne framework has a real coverage figure the owner recognises as true.

4

Bring in the control owners

You
  • Walk each owner through their own controls, not the whole platform. Fifteen minutes each beats one hour-long all-hands.
  • Show them the evidence request queue and how to close an item.
  • Set the expectation that evidence is filed when the work happens, not the week before an audit.

Done whenOwners are closing their own evidence requests without being chased.

5

Set the rhythm

You
  • Put policy reviews, access recertification and risk assessment on the schedule with real dates.
  • Agree a monthly half-hour where the owner reviews coverage and overdue items. Short and regular beats long and quarterly.
  • Turn on notifications for expiring evidence, so the system chases instead of a person.

Done whenA month passes with no manual chasing and nothing falls overdue.

6

Open it outward

Together
  • Publish the trust page and put the link where sales can reach it.
  • Give your assessor scoped read-only access rather than exporting a folder of screenshots.
  • Generate the reports your auditor asks for and check they say what you expect before the audit, not during it.

Done whenA customer security questionnaire is answered with a link.

7

Add the second framework

Together
  • Install it and let the overlap map itself against the evidence you already hold.
  • Work only the delta. This is where the platform pays for itself, and the team will feel it.
  • Review the control profile: comprehensive where it matters, lighter where it does not.

Done whenThe second framework reaches useful coverage in a fraction of the first one's effort.

Sequence, not schedule. Phases are ordered by dependency. Elapsed time depends on your change process and scope, so we do not guess at it — ask us and we will estimate against your specifics.

Is this the right pattern?

We would rather send you to another pattern than sell you the wrong one.

Choose this when

  • Procurement or your own policy requires single-tenant infrastructure.
  • You want the platform reachable only from your own network addresses.
  • You want dedicated infrastructure without taking on the operational burden of running it.

Look elsewhere when

  • Evidence must remain inside accounts you own — see Pattern 3.
  • An IP allowlist is not enough and the endpoint must not be published at all — see Pattern 4.
  • You cannot allow a third party to operate infrastructure holding your data — see Pattern 4.

Compare

Bring us your constraints.

Residency, tenancy, egress, air gap — tell us the rule you have to satisfy and we will show you the deployment that satisfies it.

Book an architecture call All four patterns