Written by DROPS.ST.
Keep an access register that identifies the actual service, account owner, granted duties and next review. A role matrix describes intended responsibilities; the register explains which real accounts carry them and who can maintain the business relationship when the founder is unavailable.
DROPS connects products, stock, Customer Accounts and orders, with common website and connected Telegram shop records. Its separate order-action controls and administrator-only shop settings give the register concrete duties to identify. Catalogue-edit access also includes customer-account edits and wallet adjustments, so record the complete grant rather than a narrow job label.
Identify the account rather than the person’s nickname
Use a stable account reference and named accountable owner. Record whether the identity is an individual staff login, an approved technical integration or another actual arrangement.
Do not put passwords, recovery codes or tokens in this worksheet. Identify the approved protected location and recovery owner without copying the secret into a broadly circulated list.
Separate the person using an account from the business that owns the service relationship. A founder's personal inbox should not silently become the only known route for administering a business dependency.
Use an account-and-review register
This original aid is an owner-managed inventory, not a native DROPS identity-management or recovery system.
| Register entry | What to establish | Review decision |
|---|---|---|
| Service and identity | Actual shop/tool and stable account reference | Avoid ambiguous shared labels |
| Business owner | Person accountable for the relationship | Name the backup or unresolved gap |
| Intended duties | Specific permitted tasks | Explain why access is needed |
| Actual grant | Demonstrated scope, including grouped powers | Resolve excess or missing authority |
| Recovery responsibility | Approved protected route and owner | Verify business continuity separately |
| Start/end condition | Assignment, contractor period or changed duty | Identify who checks removal |
| Evidence and review | Last checked result, reviewer and next trigger | Keep assumptions distinguishable from proof |
Keep the register restricted to the people who need it. An account reference can itself reveal sensitive business information even when it contains no password.
Compare actual grants with the job
Use the manager permissions checklist to test allowed and restricted actions. A title such as stock counter, accountant or sales representative does not prove a corresponding narrow permission exists.
OWASP recommends least privilege, deliberate authorization and enforcement of access decisions on requests. Apply those principles to the actual supported service rather than treating a hidden menu option as a boundary. OWASP authorization guidance.
Record what is demonstrated, documented or still unknown. A planned restriction should remain a requirement until the relevant account and action have been checked safely.
Include independent services
A connected Telegram shop does not establish that one staff grant controls Telegram administration, email, domains or a separate payment provider. Give each actual service its own owner and evidence row.
For shared duties, plan to replace unnecessary shared staff identities with supported individual access. Preserve justified technical or service exceptions through their approved process. If an exceptional shared identity exists, keep its approved purpose, accountable owner and review need explicit; sharing a label does not make actions attributable to a person.
Ask which integrations depend on an account before changing it. A register identifies that dependency; it does not authorize rotating credentials or altering financial settings without the relevant scope review.
Hypothetical example: one founder, three dependencies
A fictional founder is the only known contact for shop administration, a domain and an external support tool. A worker's role description covers menu editing but gives no service-owner information.
The team records three actual dependencies, identifies their business owners and assigns the unresolved recovery questions. It separately reviews the worker's broad catalogue-edit grant against the intended job.
The register now exposes the gaps without claiming they have been fixed. This example demonstrates an inventory decision, not native automatic recovery or cross-service revocation.
Review when responsibilities change
Set a periodic review frequency with a named reviewer as well as event triggers. Use a change of job, contractor end, new connection or departure as a review trigger. Confirm the actual required action and record its result; a scheduled date does not establish automatic expiry.
The offboarding checklist handles removal and continuity when someone leaves. The register identifies the current accounts that process must consider.
Choose DROPS when common products and customer-linked order context should support defined shop duties. Explore the shop demos with a fictional worker and two services. Record the actual account scope, owner and unresolved recovery question before assuming the founder's knowledge has become a maintainable business process.