Who builds and owns it

If Vendor Review's source repository or Vercel project belongs only to its creator's personal account, the team may lose access when that person leaves. Check who owns both and who can maintain the application without the original builder.

Test the ownership handoff

Assume the current technical owner becomes unavailable today. Give yourself five minutes and, without using knowledge that exists only in your head, locate:

The source repository and production branch
The Vercel project and the team that owns it
Production environment-variable ownership
Deployment-protection settings
Build and runtime logs
The person authorized to ship an emergency fix

Mark each item team-owned, person-dependent, or unknown. Anything in the last two categories is a concrete transfer gap.

Record the handoff result under Builders and owners in docs/readiness.md:

Source organization:
Vercel team:
Application owner:
Technical owner:
People allowed to deploy:
Transfer procedure:

Name the application owner responsible for the vendor-review process and the technical owner responsible for keeping the application running.

Choose your path

Verify: If your organization uses Enterprise Managed Users, locate the directory group that grants access, the Vercel team role it maps to, and a recently removed test user or equivalent lifecycle evidence.

Design: If you do not have that environment, use the ownership handoff above. Record the intended directory group, team role, owner, and removal trigger as planned. You can finish the course without an Enterprise account; you just cannot claim this control is implemented.

Managed builder identity

Enterprise Managed Users connect builder accounts to the company directory. The organization controls account creation, role assignment, and deactivation. Repositories and projects remain with the organization when they were created in organizational scopes rather than personal accounts.

Enterprise Managed Users is in Private Beta for Enterprise customers. It requires enforced SAML SSO, active Directory Sync, and at least one verified domain.

This is different from application access. EMU answers who may build, configure, and deploy. It does not decide which employees may submit a vendor request.

Company directory
  └─ managed builder account
       ├─ team role
       ├─ repository access
       └─ deployment and configuration access

Record the account and team setup you tested as implemented for the lab. Label directory-managed access demonstrated if you observed it elsewhere, or planned if you only described the intended setup.

Least privilege for builders

Review who can:

Merge to the production branch
Change environment variables
Change deployment protection
View production logs
Transfer or delete the project

The roles need not be identical. A developer who can create a preview does not automatically need authority to change production identity policy.

Evidence

Date the handoff result in docs/readiness.md and name an owner for each unresolved item. After changing permissions or documenting missing details, repeat the check using only the repository and organizational systems. Leave any item that still requires the original owner's help marked person-dependent.

Commit the ownership result:

git add docs/readiness.md
git commit -m "docs: record application ownership"

Summary

Enterprise Managed Users connects builder access to the company directory. The repository and project also need organizational owners so another authorized person can maintain Vendor Review when a builder leaves.

Check your work

Ask a teammate to find the source repository, production project, environment settings, logs, and person authorized to deploy an emergency fix using only the record you wrote. Anything they have to ask you for is person-dependent. Fix the record or record the missing access and who will arrange it.