The Credential Proof Packet SOP

Purpose

To maintain a standing, versioned set of credential and insurance evidence so that any legitimate request - from a customer, a general contractor, a procurement team, or an authority - is answered from stock rather than assembled from scratch. The output is a numbered packet version whose every item has a known source, a known issue date, and a known expiry, and a release rule that prevents a stale or expired item from ever leaving the building.

This procedure owns the standing program. Deciding which subset a given audience receives, and what to refuse to send, is judgment covered in the proof packet preparation article and is not re-derived here.

Scope

Applies to all outbound evidence of the shop's licenses, certifications, registrations, insurance, and bonds, and to individual credentials of employees where a customer or authority requires them by name.

Out of scope: incoming evidence collected from subcontractors, which is a vendor file rather than a proof packet; per-job permits and inspection records, which live with the job; and personnel records, which are never part of a proof packet.

Roles and responsibilities

Definitions

• Master set. The superset of every evidence item the shop can produce. Versions are cut from it; it is never sent whole.
• Version. A dated, numbered assembly released to a specific recipient. Versions are immutable once sent.
• Freshness status. Current, flagged, or expired, evaluated per item against the rules in step 4.
• Source of truth. The body that issues and can revoke the item. A copy in a folder is never the source of truth.

Procedure

1. Maintain the master set on a monthly cadence.

On the first business day of each month, the packet owner refreshes every item in the master set from its source of truth: a fresh dated capture of each license lookup, current certificates from the broker, current good-standing evidence. Monthly is chosen so that no item in stock is ever more than about 30 days old, which is the freshness bar general contractors most commonly apply to insurance certificates.

2. Increment the version number on every refresh.

Version numbers are sequential and never reused. Each version records the date it was cut and the earliest expiry among its items, because that date is when the version stops being safe to send.

3. Acknowledge every request within one business day.

The acknowledgement either delivers the packet or names the ship date and what is being waited on. Requests do not sit unanswered while the shop chases the slowest item, because silence reads as inability.

4. Evaluate freshness per item before release.

• Current. Within its freshness window: insurance certificates issued within 30 days, license captures pulled within 14 days, good standing within the current filing period.
• Flagged. Within 30 days of expiry, or outside its freshness window but not expired. A flagged item is refreshed before release, or released only with the owner's written approval and a note stating the actual date.
• Expired. Past expiry. An expired item blocks release of the packet entirely. There is no approval path around this one, because sending an expired credential as current is a misrepresentation regardless of intent.

5. Start externally issued items first.

Anything another party has to produce - a bond confirmation, a new endorsement, a certified license history - is requested on the day the request arrives, before any internal assembly begins. Internal items are assembled while those are in flight.

6. Assemble in the recipient's own order, with a cover index.

The index lists every item, its issue date, its expiry, and its source. Where the recipient supplied a numbered list, match their numbering exactly so their reviewer can tick their own form.

7. Run the release check before sending.

Four checks, all four, every time: the legal entity name matches across every document and the contract; no item is expired and every flagged item has approval; no personal identifiers or complete policy documents are included; the index matches the contents.

8. Log the release.

Record recipient, date, version number, item list, and the earliest expiry in that version. The log is what makes recall possible in step 9, and it is the only way to know six months later exactly what a given customer holds.

9. Recall within one business day of a status change.

If any item in a released version is revoked, suspended, or cancelled, notify every recipient still holding a live version that includes it, within one business day of learning, and supply the corrected version. This is not optional courtesy. A customer relying on an item you know to be void is a materially different problem from a customer relying on one you have corrected.

10. Retire versions on a schedule.

A version is retired when its earliest expiry passes. Retired versions are kept in the log for the record but are never re-sent, and the packet owner does not keep a "latest" file on a desktop, because desktop copies are how retired versions get re-sent.

The artifact: version 14, cut on the first business day of the month

This is the manifest as it is actually kept. Every column does work; nothing here is decorative.

Earliest expiry in version 14: item 3, 22 days out. That single field is the version's real shelf life, and it drives two actions. First, item 3 is flagged, so any release including it requires either a refreshed capture after the technician renews, or the owner's written approval with the actual date stated. Second, version 14 as a whole is retired in 22 days regardless of how current everything else is, because a packet is only as current as its shortest-lived item.

Two rows are worth reading closely. Item 4 records "no expiry" as a value rather than leaving the field blank, because a blank expiry field and an unverified item look identical in a table, and the difference between them is exactly what an auditor asks about. Item 3 is flagged rather than blocked, because flagged and expired are different states with different consequences, and collapsing them into one either blocks releases that should go out or releases items that should not.

Of the ten items in this version, eight are current, one is current-permanent, and one is flagged. None is expired, so the packet is releasable, subject to the item 3 approval if the recipient's subset includes it. Note that a homeowner subset would exclude items 3, 4, 8 and 10 entirely and would release with no approval needed at all, which is why the freshness check is run against the subset being sent rather than against the whole master set.

Records and retention

• The release log, retained for the longer of your jurisdiction's period for evidencing who performed licensed work, or the term of any contract the packet supported.
• Each released version, stored immutably against its log entry.
• Recall notices sent, with dates.
• The monthly refresh record, which is what demonstrates the cadence was actually run rather than claimed.

Exceptions

An authority requesting evidence on site during an inspection is answered immediately from whatever is current, and the release check is run afterward rather than before. Do not delay an inspector to run a four-point check. Log the release the same day, and if anything sent was flagged, send the corrected item to the authority as a follow-up rather than leaving the field version as the record.

References

• The state or local licensing board's public lookup, as the source of truth for license status captures
• Your insurance broker and surety, for certificates, endorsements, and bond confirmations issued in the requesting party's form
• The secretary of state or equivalent business registry, for entity good standing
• See related: How to Prepare a Proof Packet a Customer Can Accept; Tracking Licenses and Continuing Education So Nothing Lapses; The Certificate of Insurance a Customer or GC Asks For