Northwind Cloud Inc: the same policy before and after tailoring

4. Policy Statements

• 4.1 Access follows least privilege and need-to-know: each person receives the minimum access their current role requires, as defined in the role-to-access matrix, and nothing is granted because it is convenient or because a peer has it.
• 4.2 Every person has a unique, individually attributable account. Shared accounts are prohibited except for documented break-glass credentials, which are stored in 1Password, restricted to the Security Owner and named Engineering leads, used only when normal access paths are unavailable during an incident, and rotated after every use.
• 4.3 Okta is the single source of workforce identity. Business applications are integrated with it for single sign-on and, where supported, automated provisioning and deprovisioning; applications that cannot federate are recorded in the exception register with a compensating review.
• 4.4 Multi-factor authentication is enforced for every workforce account, with phishing-resistant methods for administrative roles, under the Authentication and Password Policy.
• 4.5 Access requests are made in the ticketing system, name the system and role required, and are approved by the requester's manager and the system owner before provisioning. The ticket is the evidence of the grant and is retained for seven years under the Data Retention and Disposal Policy.
• 4.6 Production access to AWS and Vercel is granted only to engineers whose role requires it, through federated identity and short-lived credentials rather than long-lived access keys. Administrators use a separate privileged role that is assumed for a bounded session and logged to Datadog; read-only roles are used wherever write access is not needed.
• 4.7 Direct access to customer data in production databases and storage is limited to named engineers with a documented need, performed through audited tooling wherever possible, and logged. Because Northwind Cloud Inc processes PII data, every direct query against customer data is tied to a ticket or incident reference.
• 4.8 Access to GitHub is granted through organisation membership enforced by single sign-on with Okta, repository permissions are assigned by team, and protected branches require a review from someone other than the author before code is merged and deployed by GitHub Actions. Where headcount makes this impractical, the Security Owner documents the compensating review.
• 4.9 Non-human identities such as service accounts, API keys, deploy keys and integration tokens have a named human owner, a documented purpose, the narrowest permissions that fulfil it, and an entry in the service account inventory. They are never used interactively and are rotated at least annually and immediately when a person who knew the secret leaves.
• 4.10 Access is reviewed at least quarterly for production, source code, identity administration and any system holding Restricted data, and at each annual review for all other systems. Reviewers attest to each account and privileged role, and removals are completed within five business days.
• 4.11 When a person leaves Northwind Cloud Inc, their identity provider account is disabled and their sessions revoked before the end of the last working day, and all other access is removed within one business day. When a person changes role, access the new role does not require is removed within five business days.
• 4.12 Third-party and vendor access is sponsored by a named employee, covered by a signed agreement with confidentiality terms, limited to the specific systems and duration needed, provisioned through individual accounts, and removed at the end of the engagement. Because Northwind Cloud Inc operates a Remote work model, no access decision is based on network location: internal systems are reached through authenticated, encrypted connections that verify the user and device.

5. Procedures

• 5.1 Onboarding and additional access. People Operations opens an onboarding ticket at least three business days before the start date, stating the role. Engineering provisions the standard bundle for that role in Okta, GitHub and the relevant groups in AWS and Vercel, activated no earlier than the first working day. Requests beyond the bundle are raised as tickets, approved by the manager and the system owner (the Engineering lead for production, the Security Owner for identity and security tooling), and closed with a note of the permission granted.
• 5.2 Production access grants. An engineer requesting a production role in AWS and Vercel states the reason and expected duration. The Engineering lead approves, the Security Owner is notified, and the role is assigned through identity federation with a session limit of no more than twelve hours. Temporary grants carry an expiry and are removed on that date.
• 5.3 Quarterly access review. Within the first two weeks of each quarter the Security Owner exports user and role lists from Okta, the identity services of AWS and Vercel, GitHub, Supabase, Stripe, Datadog and Slack and production databases, reconciles them against the personnel list from People Operations, and sends each system owner their list for attestation. Owners respond within ten business days, removals are completed within five business days of the response, and the signed-off review is retained as evidence.
• 5.4 Offboarding and role changes. When People Operations confirms a departure, Engineering disables the Okta account, revokes sessions and tokens, removes membership of GitHub and AWS and Vercel, and rotates any shared or break-glass credentials the leaver could have known. The checklist is completed on the last working day and verified by the Security Owner within one business day. For internal moves, Engineering removes any access the new role's matrix entry does not require within five business days.
• 5.5 Service account inventory. Engineering maintains an inventory of every non-human identity with its owner, purpose, permissions, secret location and rotation date. It is reviewed in the quarterly access review, orphaned identities are removed, and any key older than twelve months is rotated.
• 5.6 Break-glass use. Use is announced in the incident channel, the reason is recorded in the incident ticket, the credential is rotated within one business day, and the Security Owner reviews every use.
• 5.7 Third-party access. The sponsoring employee raises a ticket with the vendor contact, systems, permissions, justification and end date. The Security Owner confirms a signed agreement exists under the Vendor and Third-Party Risk Management Policy, Engineering provisions individual accounts with an expiry, and the sponsor confirms removal on the end date.
• 5.8 Monitoring of access changes. Engineering configures alerts for privileged role assignments, new administrative users, identity provider policy changes and disabled multi-factor authentication in Datadog. The Security Owner reviews these alerts weekly and investigates any change without an approved ticket.

4. Policy Statements

• 4.1 Okta is the single source of workforce identity for Northwind Cloud Inc. Every person receives exactly one Okta account, created from the onboarding ticket, and every business application, including AWS, GitHub, Datadog, Slack, 1Password and Stripe, is reached through Okta single sign-on. Vercel and Supabase, which are not federated to Okta on Northwind's current plans, are recorded in the exception register with the quarterly access review as the compensating control.
• 4.2 Access is assigned by Okta group membership, never by direct application assignment to a person. The role-to-access matrix maps each job role to a set of Okta groups (eng-all, eng-production, eng-production-admin, okta-github, okta-aws, finance-stripe and support-tier1), and Okta group rules assign the standard groups automatically from the department and title attributes. Any group outside the standard bundle for a role requires a ticket approved by the requester's manager and the system owner.
• 4.3 Every workforce account authenticates with multi-factor authentication enforced by the Okta global session policy. Access to the Okta Admin Console, AWS IAM Identity Center, the GitHub organisation and Datadog is governed by Okta authentication policies that require a phishing-resistant factor: Okta FastPass on a Kandji-managed Mac or a FIDO2 security key. SMS, voice and email one-time codes are disabled in the authenticator enrolment policy.
• 4.4 Production access to AWS is granted only through AWS IAM Identity Center permission sets federated from Okta and synchronised by SCIM. IAM users with long-lived access keys are prohibited for people; the IAM credential report is checked at every quarterly access review and any human IAM user found is removed. Engineers in eng-production hold the NorthwindReadOnly permission set by default, and the NorthwindProductionAdmin permission set is assigned only to the eng-production-admin Okta group with a session duration of eight hours.
• 4.5 Direct access to customer data in the Supabase production project is limited to engineers in the eng-production Okta group. Because Northwind processes personal data, every query against production tables is run through the Supabase SQL editor or an audited session and is tied to a ticket or incident number. Row Level Security is enabled on every table exposed through the Supabase API, and the service_role key is stored only in AWS Secrets Manager and as a Vercel sensitive environment variable and is never used interactively.
• 4.6 Membership of the Northwind GitHub organisation is enforced through SAML single sign-on with Okta and SCIM provisioning from the okta-github group; two-factor authentication is required for all members and the organisation base permission is set to No permission. Repository access is granted to GitHub teams that mirror Okta groups, and the main branch of every deployable repository is protected by an organisation ruleset requiring one approving review from a non-author, passing GitHub Actions status checks and no force pushes, with an empty bypass list so organisation owners are not exempt.
• 4.7 Deployments to production use short-lived credentials only. GitHub Actions assumes the northwind-deploy AWS role through OpenID Connect federation, and Vercel deploys from the protected main branch through its Git integration. No long-lived AWS access keys, Vercel tokens or Supabase keys are stored as GitHub repository or organisation secrets, and the production GitHub environment requires a reviewer from the Engineering lead team.
• 4.8 Shared credentials are prohibited except for the two documented break-glass identities: the AWS management account root user and the Okta emergency super administrator. Their passwords and hardware security keys are held in the 1Password vault named Break Glass, shared only with Dana Whitfield and the two named Engineering leads, and rotated within one business day of every use. Every 1Password account is unlocked through Okta, and 1Password Watchtower reports are reviewed monthly.
• 4.9 Access to Northwind systems requires a company-managed device. Kandji enforces FileVault, the macOS firewall, automatic operating system updates and a fifteen-minute screen lock on every Mac, and Okta device assurance policies deny access to AWS, GitHub, Datadog and the Okta Admin Console from a device that is not enrolled in Kandji or that fails the disk encryption or minimum OS version checks.
• 4.10 Non-human identities, including AWS IAM roles for services, the Supabase service_role key, Datadog API and application keys, Stripe restricted API keys, Slack bot tokens and GitHub Apps, are recorded in the service account inventory with a named owner, purpose, permissions and rotation date. They are scoped to the minimum permissions required, rotated at least annually and immediately when a person who knew the secret leaves, and stored in AWS Secrets Manager, Vercel sensitive environment variables or 1Password, never in source code.
• 4.11 Access is reviewed quarterly for Okta administrators, AWS permission set assignments, GitHub organisation owners and teams, Vercel team members, Supabase organisation members, and Datadog and Stripe administrators, and at the annual policy review for every other application. Removals identified in a review are completed within five business days and recorded in the review ticket.
• 4.12 When a person leaves Northwind Cloud Inc, their Okta account is deactivated before the end of their last working day, which revokes Okta sessions and deprovisions every SCIM-connected application. All remaining access, including direct Vercel, Supabase and Stripe membership, 1Password vault access and Kandji device assignment, is removed within one business day, and the laptop is remotely locked through Kandji until it is returned.

5. Procedures

• 5.1 Onboarding. People Operations opens the onboarding ticket at least three business days before the start date with the role and manager. Dana Whitfield maps the role to the role-to-access matrix, Engineering creates the Okta account and confirms that group rules have assigned the standard groups, the laptop is enrolled in Kandji through Automated Device Enrollment before it ships, and the new hire sets up Okta FastPass and their 1Password account on the first day. The ticket is closed with the list of Okta groups granted.
• 5.2 Additional access. A request for an Okta group outside the standard bundle for a role is raised as a ticket naming the group and the reason. The requester's manager and the system owner approve in the ticket: the Engineering lead for AWS, GitHub, Vercel and Supabase; Dana Whitfield for Okta, Datadog and 1Password; the finance lead for Stripe. Engineering adds the person to the Okta group and closes the ticket with the group name and date.
• 5.3 Production access grants. An engineer requesting the NorthwindProductionAdmin permission set states the reason and expected duration in a ticket. The Engineering lead approves, Dana Whitfield is notified, and the engineer is added to the eng-production-admin Okta group, which IAM Identity Center picks up on the next SCIM sync. Temporary grants carry an expiry date in the ticket, and the Engineering lead removes the group membership on that date.
• 5.4 Quarterly access review. Within the first two weeks of each quarter Dana Whitfield exports the Okta user list and group memberships, the IAM Identity Center permission set assignments, the GitHub organisation members and teams, the Vercel team members, the Supabase organisation members, the Datadog user list and the Stripe team list, and reconciles them against the headcount list from People Operations. Each system owner attests to their list within ten business days, removals are made within five business days, and the exports and attestations are stored in the compliance evidence folder.
• 5.5 Offboarding. When People Operations confirms a departure, Engineering deactivates the Okta account before the end of the last working day, which revokes Okta sessions and removes the person from AWS IAM Identity Center, GitHub, Slack, Datadog and 1Password through SCIM. Engineering then removes any direct Vercel, Supabase and Stripe membership, rotates any break-glass or shared secret the leaver could have known, and issues a Kandji remote lock. Dana Whitfield verifies the completed checklist within one business day.
• 5.6 Role changes. People Operations notifies Dana Whitfield of a change in role. Dana compares the person's current Okta groups with the matrix entry for the new role, and Engineering removes any group the new role does not require within five business days. Okta group rules re-evaluate automatically when the title or department attribute changes; manually assigned groups are adjusted in the ticket.
• 5.7 Service account inventory. Engineering maintains the inventory of non-human identities in the security repository, listing each AWS IAM role, the Supabase service_role key, Datadog API and application keys, Stripe restricted keys, Slack app tokens and GitHub Apps with its owner, purpose, permissions, secret location and last rotation date. The inventory is reviewed in the quarterly access review, orphaned identities are deleted, and any secret older than twelve months is rotated.
• 5.8 Break-glass use. The AWS root user and the Okta emergency super administrator are used only when normal access through Okta is unavailable during an incident. The engineer announces the use in the #security-incidents Slack channel, retrieves the credential from the 1Password Break Glass vault, and records the reason in the incident ticket. Dana Whitfield rotates the credential and reviews the corresponding CloudTrail or Okta System Log entries within one business day.
• 5.9 Third-party access. An employee sponsoring vendor access raises a ticket with the vendor contact, the systems and permissions needed, and an end date. Dana Whitfield confirms that a signed agreement is on file under the Vendor and Third-Party Risk Management Policy, Engineering creates an individual Okta account or a time-limited GitHub outside collaborator invitation, and the sponsor confirms removal on the end date.
• 5.10 Monitoring of access changes. Engineering streams the Okta System Log, AWS CloudTrail and the GitHub organisation audit log into Datadog. Datadog monitors alert the #security-alerts Slack channel on Okta administrator role assignments, authentication policy changes, new IAM Identity Center permission set assignments, GitHub organisation owner changes, ruleset changes and disabled MFA factors. Dana Whitfield reviews the alerts weekly and matches each one to an approved ticket.

Implementation notes for Northwind Cloud Inc

• Okta: create the groups eng-all, eng-production, eng-production-admin, okta-github, okta-aws, finance-stripe and support-tier1 and add group rules keyed on the department and title attributes so standard access is assigned automatically. Enable SCIM provisioning for the AWS IAM Identity Center, GitHub, Slack, Datadog and 1Password applications, and set the Okta Admin Console, AWS and GitHub authentication policies to accept only Okta FastPass with hardware-protected keys or FIDO2 as authenticators.
• AWS: enable IAM Identity Center in the management account with Okta as the external identity source and SCIM turned on, create the NorthwindReadOnly and NorthwindProductionAdmin permission sets with an eight-hour session duration, and enable the iam-user-no-policies-check, iam-root-access-key-check and iam-user-unused-credentials-check AWS Config rules plus a Datadog monitor on CloudTrail that alerts on any IAM user creation or root sign-in.
• GitHub: in the organisation settings enable SAML SSO with Okta, turn on Require SAML SSO and SCIM provisioning, require two-factor authentication, set base permissions to No permission, and create an organisation ruleset targeting the default branch of all repositories with required pull request reviews (one approval, dismiss stale approvals, require review from code owners), required status checks and blocked force pushes, leaving the bypass list empty.
• Kandji: create a Blueprint for engineering Macs with FileVault key escrow, the firewall, automatic updates, a fifteen-minute screen lock and the Okta Verify library item, and connect Kandji to Okta as a device management partner so Okta device assurance policies can check management state, disk encryption and OS version before allowing access to AWS, GitHub and Datadog.
• 1Password: enable Unlock with Okta and the SCIM bridge for the business account, create the Break Glass vault shared only with Dana Whitfield and the two Engineering leads, turn on Watchtower and the monthly insights report, and move every shared operational secret into team vaults so nothing remains in Slack messages or personal notes.
• Vercel and Supabase: limit the Owner role on both to two named people, require every Vercel member to sign in with their GitHub identity so GitHub's two-factor requirement applies, enforce multi-factor authentication at the Supabase organisation level, store the Supabase service_role key only as a Vercel sensitive environment variable and in AWS Secrets Manager, and enable Supabase network restrictions so direct Postgres connections are accepted only from the AWS NAT gateway addresses and the engineering VPN.