# An enterprise QR code policy you can adopt

> An enterprise QR policy needs five parts, approved client-side or self-hosted generators, own-domain-only destinations with no third-party shorteners, design standards that label every destination in plain text, a registry of deployed codes with owners and review dates, and a scheduled physical audit plus an incident playbook for reported malicious codes.

Source: https://useqr.app/docs/security/enterprise-qr-code-policy · Last reviewed 2026-08-21 · UseQR is free forever, no signup.

---

## Why a policy at all

A QR code asks customers to trust a destination no human can read, printed on surfaces
anyone can alter, generated by whichever tool a marketer found first. The failure modes
are all documented: [stickers over genuine
codes](/docs/security/qr-code-stickers-placed-over-real-ones), shortener links that
[expire under printed material](/docs/troubleshooting/qr-code-link-shortener-expired),
credentials typed into third-party generators. Each is cheap to prevent by rule and
expensive to fix by incident. What follows is written to be adopted as-is and trimmed to
fit.

## 1. Approved generators

- Codes are generated **client-side or on self-hosted infrastructure**: payloads
  containing credentials, personal data or unreleased URLs must not transit third-party
  servers. The reasoning is in
  [client-side vs server-side generation](/docs/security/client-side-vs-server-side-qr-generation);
  the build-it-yourself option in
  [self-hosting a QR generator](/docs/developers/self-hosting-a-qr-generator).
- Approved tools must be **verifiable**: demonstrably functional offline, or with published source you can read. Offline capability is the stronger test, because you can run it yourself in ten seconds.
- Server-rendered APIs are permitted for **public URLs only**.

## 2. Domain rules

- Codes point **only at domains the organisation owns**. No third-party
  [shorteners](/glossary/short-url). They hide the destination from customers and add a
  dependency that can expire or be acquired.
- If dynamic redirection is genuinely needed, it runs on a **custom domain you own**, so
  the provider can be swapped without reprinting, the escape route described in
  [migrating off a dynamic provider](/vs/how-to-migrate-off-a-dynamic-qr-provider).
- Destination pages must be maintained for the printed material's full lifetime.

## 3. Design standards

- The **destination domain is printed in plain text** beside every code, and the call to
  action states what scanning does.
- Codes meet print minimums: [quiet zone](/glossary/quiet-zone) of at least **4 modules**,
  size per the **10:1 distance rule** (check with the
  [size calculator](/size-calculator)), contrast of at least **40%** luminance difference,
  dark on light.
- Payment codes print the **payee name large** next to the code.

## 4. The code registry

Untracked codes cannot be audited, renewed or recalled. One row per deployed code:

| Field | Example |
|---|---|
| Code ID | `2026-081` |
| Destination | `https://example.com/menu` |
| Owner | Named person, not a team |
| Placements | Reception standee; table tents 1–24 |
| Created / review date | 2026-08 / 2027-02 |
| Generator used | Approved tool name |

Bulk campaigns come out of the [bulk generator](/bulk) with the registry spreadsheet as
input, so the inventory exists before the print run does.

## 5. Print audit cadence

- **Weekly** for public payment surfaces; **monthly** for premises codes; **per
  placement** for campaigns.
- Each audit: feel for sticker edges, confirm
  [tamper-evident labels](/docs/security/tamper-evident-qr-labels) are intact, scan with
  a [decoder](/scan) and match the destination against the registry.
- Audits are a named duty on an existing checklist, with the registry recording the last
  pass.

## 6. Incident playbook: a reported malicious code

1. **Photograph** the code and its surroundings before touching anything.
2. **Cover or remove** it immediately.
3. **Decode from the photograph** in isolation: upload to a [scanner](/scan) rather than
   following the link on a phone.
4. **Check the registry**: substituted genuine code, or foreign placement?
5. **Sweep** sibling placements for the same tampering.
6. **Notify** security and communications; if payments were diverted, the payment
   platform and police.
7. **Record** the incident and feed it into training.

## 7. Training

The policy's human layer is rehearsal:
[QR codes in security awareness training](/docs/security/qr-codes-in-security-awareness-training)
covers running simulations that teach staff and measure the policy's blind spots.

## FAQ

### What should a QR code policy include?

Approved generators, domain rules, design standards, a registry of deployed codes, a
physical audit schedule, an incident playbook and a training loop. The registry is the
keystone: every other control depends on knowing what is deployed where.

### Should companies use URL shorteners in QR codes?

No. Shorteners hide the destination from the person scanning, add a third-party
dependency that can expire or change hands, and train customers to trust unreadable
links. Point codes at owned domains, with the domain printed beside the code.

### Who should own QR codes in an organisation?

Each deployed code needs a named individual owner recorded in the registry, responsible
for its destination staying live and its placements passing audit. Codes owned by "the
marketing team" are owned by nobody.

### How often should printed QR codes be audited?

Weekly for public payment surfaces, monthly for other premises codes, and once per
placement for campaign material. An audit is seconds long: feel for overlays, rescan,
and verify the destination against the registry.

## Try it

- https://useqr.app/url
- https://useqr.app/bulk
- https://useqr.app/validate
- https://useqr.app/scan