22 security controls, one supplier scheduling platform

The Challenge

Supplier engineers visit the factory constantly for calibration, line maintenance, installation and audits. Every visit needs a slot, a host, a purpose, and a record. That coordination lived in email threads and a shared spreadsheet, which meant double bookings, engineers arriving for hosts who were on leave, and no reliable answer to a question the business asks often: who was on site, when, and why.

The obvious fix is a scheduling tool. The difficulty is that the people doing the booking are not employees. Giving external suppliers a login into anything that touches plant operations turns a convenience problem into a security problem, and a security problem at an enterprise of this size means a formal review: twenty-two controls covering authentication, authorisation, data residency, logging, session handling, encryption, and incident response. Fail one and the system does not launch.

Most vendors build the scheduler and treat security as a hardening pass at the end. That order is what makes these projects die in review.

Our Approach

We inverted it. The control list was the specification, not the acceptance test. Before any scheduling logic existed we designed the identity model, because every other control hangs off it.

Four role types, with genuinely different powers. Supplier engineers see only their own company's bookings and can request, reschedule, or withdraw a visit. Nestlé hosts see requests directed at them and can accept, decline, or issue a counter-proposal. Site coordinators see the whole calendar for their site and resolve conflicts. Administrators manage roles and read the audit log, but cannot silently alter a booking record. Administrative edits are themselves logged events.

Authorisation is enforced server-side on every request, not by hiding buttons. Internal users authenticate through the client's existing Entra tenant, so no employee credential is ever held by the application. External suppliers get scoped accounts with mandatory rotation and no lateral visibility: a supplier cannot discover that a competitor is also on site.

Every state change writes an append-only audit event: actor, action, target, timestamp, prior value. That single design decision satisfied six of the twenty-two controls on its own.

What We Built

Go See is a booking surface that behaves the way people already expect a calendar to behave. An engineer proposes a window. The host sees it in context against their own schedule and either accepts or proposes a different window back. The counter-proposal flow is the part that removed most of the email: a declined booking is rarely a refusal, it is usually a negotiation, and the system now carries that negotiation instead of an inbox.

Coordinators get a site-wide view with conflict detection: two engineers booked into the same line, a visit with no host assigned, a request left unanswered past its lead time. Each one surfaces as an item to resolve rather than a surprise on the day.

The audit view is available to administrators as a searchable record. When the business asks who was on site during a given shift, the answer takes seconds and stands up to scrutiny.

Results

• All 22 enterprise security controls passed at formal review
• 4 role types with server-enforced, non-overlapping permissions
• 100% audit compliance, with every state change attributable to an actor
• Supplier visit coordination moved off email and shared spreadsheets
• Counter-proposal flow removed the majority of scheduling round-trips

Technologies

Next.js · role-based access control · append-only audit logging · Microsoft Entra SSO · PostgreSQL · encryption at rest and in transit

What This Means for Other Enterprises

Any enterprise that lets outsiders touch an internal system faces this exact shape of problem: contractor portals, dealer networks, distributor ordering, third-party logistics, clinical or field partners.

The lesson transfers cleanly: treat the security review as the design input. Model identity and audit before features, enforce authorisation on the server, and make every state change an event. Built in that order, a twenty-two control review is a formality. Built in the other order, it is where the project stops.