Knowledge · Business Operations

    Access-Control Verification Checklist

    A practical checklist for testing whether the permissions in your business software are real, using accounts you already have and no special tooling.

    How do I check whether my software's permissions actually work?

    Create a second organization and a low-privilege user, then try to reach things you should not: another tenant's record by direct identifier, a restricted page by direct address, a sensitive field in an export, and a deleted record in search. Real controls refuse all four; interface-only controls refuse none of them.

    Key takeaways

    • Test with the least-privileged account, not the owner account.
    • Address resources directly rather than clicking through the interface.
    • Check exports and reports separately — they bypass page-level rules.
    • Verify that soft-deleted records stay gone everywhere.
    • Ask the vendor what enforces a control, not whether the control exists.

    Tenancy

    • Sign in as a member of organization A and request a record identifier belonging to organization B.
    • Repeat for a write, not only a read.
    • Repeat for a file download and for anything that streams live updates.
    • Confirm the refusal is a refusal, not an empty page that still performed the write.

    Role boundaries

    • As a viewer, open a restricted route by typing its address.
    • As a viewer, attempt an export and check which fields appear.
    • As a working member, attempt an action reserved for administrators.
    • Confirm that a hidden menu item corresponds to an actual refusal, not just a missing link.

    Attribution and reversibility

    • Perform a destructive action and confirm the history names the actor and the time.
    • Perform an automated or assistant-initiated action and confirm it is attributed to that actor, not to a person who was not involved.
    • Delete a record and search for it in every surface: lists, reports, exports, global search.
    • Restore it and confirm its history and identifier survived.

    Questions worth asking a vendor

    • What enforces this — the interface, the API, or the database?
    • Where does the organization on a write come from?
    • What happens to an action if audit logging fails?
    • Which operations are irreversible, and who can perform them?
    • How is access reviewed, and how quickly is it removed when someone leaves?

    Where URBLD fits

    URBLD's access control policy requires access to be reviewed at least quarterly and removed the same day an engagement ends, and multi-factor authentication is required for accounts holding privileged roles, with enrolment measured rather than assumed. An internal coverage check enumerates expected table, role and operation combinations and reports policy gaps, so missing enforcement is found by inspection instead of by incident.

    Principles reinforced

    This page rests on the following foundational ideas.

    FAQ

    Frequently Asked Questions

    Straight answers about how URBLD runs the business end-to-end.

    More in Business Operations

    The daily mechanics: workflows, checklists, scheduling and handoffs.

    Browse Business Operations
    Share this page