A permits vendor account was granted db_owner for convenience. What should county IT do to restore least privilege?

Revoking db_owner and replacing it with object-level grants limited to the vendor’s required tables and procedures restores least privilege for a permits vendor account that was over-granted for convenience. db_owner can alter schema, drop objects, change permissions, and read broadly inside the database—far beyond a vendor integration’s need to call specific procedures or read specific permits tables. Object-level GRANT SELECT/EXECUTE on just those artifacts shrinks blast radius while preserving the vendor’s legitimate automation.

Leaving db_owner in place and adding the vendor to sysadmin fails by concept: it escalates from database owner to server-level superuser. Sharing the permits sa password with the vendor team for after-hours fixes multiplies credential sprawl and equates vendor support with the highest SQL privilege. Granting CONTROL SERVER so object-level permissions are “unnecessary” deliberately abandons least privilege at the instance scope.

Exam caveat: Least privilege on DP-800 is usually expressed as object-level or schema-scoped grants, roles tailored to an app, or Entra group–mapped users—not shared sa/db_owner. When vendors need temporary elevation, use time-bound just-enough access with auditing rather than permanent db_owner. Also revoke residual memberships after redeploying permissions from source-controlled scripts.

Operational check: Inventory exactly which permits tables and procedures the vendor calls, create a role with only those grants, add the vendor user to that role, and revoke db_owner/sysadmin. Negative-test that DDL and access to unrelated schemas fail. Rotate any shared sa passwords that were disclosed, enable auditing on the vendor principal, and encode the role definition in the SQL Database Project so future convenience grants cannot silently return via manual hotfixes.