A key-control register does not stop every key from being lost. It gives manufacturers, distributors, and site custodians a shared record of what was issued, who received it, what asset it relates to, and whether the transaction was closed.
This guide provides a practical key-control register template for cabinet and locker programs. It is designed for B2B product and after-sales workflows. It does not describe key cutting, lock bypass, rekeying, or a specific WELLHW product capability.
Quick Answer
Build the register around five questions: Which project and asset does the key serve? What internal identifier tracks it? Who is responsible for it? When was it issued or returned? What action was taken if it was lost, stolen, damaged, or retired?
Use internal control IDs instead of recording key cuts or other sensitive keying data in an ordinary shared sheet. Assign one owner to maintain the register, restrict access, and reconcile open transactions on a defined schedule.
What This Template Is, and What It Is Not
This template is an operational record for cabinet, locker, office furniture, storage, or similar keyed-product programs. A manufacturer can use it to define the data delivered with a project. A distributor can use it to map shipments and replacement references. A facility custodian can use it to record issue and return activity.
It is not a master-key schedule, a locksmithing instruction, or a universal compliance standard. Organizations with regulated sites or formal security policies should have their security owner adapt the template to the applicable requirements.
Why a Register Is a Useful Starting Point
Formal key-control programs often separate two records: an inventory of keys and locks, and a transaction history for issue and return. The FAA’s Key and Lock Control guidance, for example, describes unique identifiers, issue-and-return records, inventories, holder records, and lost-key reporting.
Those documents govern their own organizations. They are not cabinet-manufacturing standards. The useful principle for a commercial program is simpler: keep asset identity, custody, transaction status, and incident decisions traceable without exposing sensitive keying information.
Key-Control Register Fields
The table below is a starting data dictionary. Add or remove columns based on the project, but define each field before the first shipment.
| Field | What to record | Why it matters |
|---|---|---|
| Program reference | Customer, project, purchase order, site, or building code | Separates one deployment from another |
| Product reference | Furniture SKU, cabinet model, locker bank, or approved lock-family reference | Connects the record to the product documentation |
| Asset or lock ID | A unique internal identifier for the door, compartment, or lock | Defines the physical scope of the record |
| Key control ID | A non-sensitive internal tracking number | Tracks the item without displaying key-cut data |
| Access group | An approved internal group label | Shows which assets share an authorized access relationship |
| Quantity | Number issued, returned, in stock, or retired | Makes reconciliation possible |
| Holder or custodian | Authorized person, department, installer, or controlled storage location | Assigns current responsibility |
| Issue record | Date, issuer, recipient, and transaction reference | Documents the handoff |
| Return record | Date, receiver, returned quantity, and condition | Closes the transaction |
| Status | In stock, issued, returned, lost, stolen, damaged, or retired | Allows teams to filter unresolved items |
| Replacement reference | Approved service part, drawing, supplier reference, or support ticket | Links the incident to controlled after-sales information |
| Review date | Last reconciliation and next scheduled review | Prevents the register from becoming a static archive |
A Copy-and-Use Column Order
For a spreadsheet or database, start with this order:
Program Reference | Product Reference | Asset ID | Key Control ID | Access Group | Quantity | Holder/Custodian | Issue Date | Issued By | Return Date | Received By | Status | Replacement Reference | Incident Reference | Last Review | Next Review | Notes
Use dropdown values for status and access group where possible. Free-text labels create duplicates such as “returned,” “Return,” and “back in stock,” which make reporting unreliable.
Keep Sensitive Keying Data Out of the Shared Register
A general operations sheet should not contain key cuts, bitting, duplication instructions, or bypass-sensitive details. If a controlled technical record is required, store it separately with access limited to authorized personnel. The general register can point to that record using a reference number.
The FAA guidance above treats key and lock records as controlled information and describes secure handling for records and keys. The exact controls for a commercial project should be set by the organization’s security owner, not copied blindly from another institution.
Five-Step Operating Workflow
1. Define ownership before shipment
Name the register owner, the people allowed to issue or receive keys, and the person who approves incident actions. If ownership changes at delivery, document the handover from manufacturer or distributor to the site custodian.
2. Allocate identifiers
Assign the program, product, asset, and key-control references before keys are distributed. Do not use a person’s name as the only identifier because holders and roles change.
3. Record each transaction
Log issue and return as separate events. Record the quantity, date, issuer, recipient, and condition. A key marked “issued” should remain open until a return or approved status change is recorded.
4. Reconcile the register
Choose a review interval appropriate to the site and risk. Compare stock, open transactions, and retired items. The U.S. Fish and Wildlife Service’s key-control policy, for example, requires inventories in its own facilities and identifies fields such as keys, locks, serial numbers, locations, and quantities. Commercial teams can adapt the inventory principle without treating that policy as a universal schedule.
5. Close incidents
When a key is reported lost, stolen, or damaged, open an incident record and assign a decision owner. Do not leave the status as a free-text note. Record the authorized action, completion date, and the service or replacement reference used.
Lost-Key Incident Addendum
| Incident field | Required entry |
|---|---|
| Incident reference | Unique ticket or case number |
| Report details | Date, reporter, and current status |
| Affected scope | Program, asset IDs, and access group |
| Decision owner | Authorized person or role |
| Approved action | A reference to the authorized service decision, without technical bypass instructions |
| Closure | Completion date, service reference, and verification status |
A register supports the decision process, but it should not tell an unqualified person how to open, alter, or rekey a lock. Route physical service work to an authorized provider using the approved product documentation.
Responsibility Across the Supply Chain
| Role | Typical register responsibility |
|---|---|
| Manufacturer | Define product references, asset-label format, documentation handoff, and approved replacement-reference fields |
| Distributor or project integrator | Map shipments, sites, project references, and handover records |
| Site custodian | Control storage, issue and return transactions, inventory, and incident reporting |
| Authorized service provider | Return the approved service reference and completion status to the register owner |
The operating principle is to make each handoff and open exception visible to the responsible organization. The exact approval roles, retention rules, and review frequency should come from that organization’s own policy.
Common Register Mistakes
- Using key-cut data as the visible identifier. Use a non-sensitive control ID and keep technical records separate.
- Mixing manufacturer and facility responsibilities. State who owns product references, transactions, incidents, and approvals.
- Recording issue but not return. Require a closure field and review open transactions.
- Allowing uncontrolled status text. Use approved dropdown values so the register can be filtered and reconciled.
- Treating an old product description as a service decision. Link to the currently approved drawing, part reference, or support case instead.
- Keeping the register without an access policy. Limit permissions and retain only the personal data needed for accountability.
Related Planning Guides
The register answers “what do we track?” It does not answer “which key system should we buy?” Use these separate guides for those decisions:
- Keyed Alike vs Keyed Different vs Master Key
- How Office Furniture Manufacturers Can Standardize Replaceable File Cabinet Locks
- Mailbox Lock Replacement and Key-Loss Support Planning
- Browse the WELLHW lock-cylinder category
Prepare a Clear Product Inquiry
When requesting a product review, send the application, product or drawing reference, required quantity, project grouping, asset-label plan, and the replacement-reference fields your after-sales team needs. Final compatibility and key-system capability should be confirmed against the current approved product specification.
Contact WELLHW with the project information you can share. Do not send key cuts, bitting, or other sensitive access data through a general website form.
FAQ
Is a key-control register the same as a key schedule?
No. The register tracks inventory, custody, issue, return, status, and incidents. A technical key schedule describes access relationships and other controlled keying information. Keep the technical record separate and access-restricted.
Who should own the register?
Assign one accountable owner for each stage. The manufacturer or integrator may prepare the initial asset data, while the site custodian normally owns day-to-day issue, return, inventory, and incident records after handover.
Should the register include key cuts or bitting?
Not in an ordinary shared sheet. Use a non-sensitive control ID and point to a separately controlled technical record if authorized personnel need it.
How often should the register be reviewed?
Set the interval according to the site’s risk, applicable policy, and transaction volume. Also reconcile it at handover, role changes, incident closure, and program retirement.
