POS operations guide
POS system audit checklist for an operating shop
A useful POS audit does not ask whether the screen looks normal. It proves who can act, whether known transactions reconcile, which devices and providers remain dependencies, whether a backup restores, and who owns every unresolved gap. Use this recurring review after go-live, not as a substitute for local professional or compliance assessment.
Evidence and review scope
Evidence reviewed 2026-08-18. Pinned source at exact commit b531ef4308c4dc3a25f250551a54fc5616e3b8d9, the exact v1.3.0 lockfile, 130 focused passing tests across 15 files, one production-dependency audit and current primary guidance from NIST, PCI SSC and GS1.
Stable release: v1.3.0. No customer shop, complete shift, physical device set, payment authorization, accounting close, tax result, security assessment or production recovery was audited. The v1.3.0 production dependency audit also found one high transitive js-yaml advisory; a later source commit resolves it, but that source was not a newer stable package.
What the current evidence establishes
130 tagged-release checks passed
After npm ci installed the exact v1.3.0 lockfile, 130 tests passed across authentication, lock-screen behavior, secret defaults, telemetry absence, data health, sales call paths, import templates, receipt reports, print-document isolation, backup paths, logs and update controls. Source tests do not prove one shop's records.
Access controls need observed role tests
The focused run checked saved-session validation and lock-screen behavior. It did not prove that one business configured every owner, manager, cashier and support account correctly or that every sensitive workflow has the required approval.
Records must reconcile outside the dashboard
Report formatting, sales call paths and duplicate-record health checks passed their focused tests. A shop still needs known sale, discount, void, return, tax, stock, cash and provider cases whose source records can be reconciled independently.
Backup evidence includes a bounded restore
Existing evidence records a synthetic restore of 20 collections and 53 documents plus 14 passing backup-path tests. That is not proof of the selected shop's backup location, retention, off-machine copy, recovery time or latest restore.
Dependency status is part of the audit
npm audit --omit=dev found one high transitive js-yaml 4.3.0 advisory in the stable lockfile through electron-updater. Pinned source commit 612b4f11635d8dcc5f74acd6bfc38ff46739a3e7 resolves js-yaml 4.3.1 and returned zero production findings, but unreleased source is not the installed stable package.
No certification or customer outcome is claimed
The run used source and synthetic evidence only. No independent security audit, card assessment, local tax review, physical printer or scanner test, payment settlement, customer data set, complete trading day or production incident was accepted for this page.
Audit ten operating decisions with separate evidence
For every area, record the exact configuration, test sample, observation and owner. A feature name, green dashboard or downloaded checklist is not a pass.
| Audit area | Current Posnic evidence | Evidence the operating shop must keep |
|---|---|---|
| Release and dependencies | The stable release, source commit, lockfile and one current advisory are pinned. | Installed version, package hashes, update channel, current advisory decision and rollback owner. |
| Users and access | Saved-session and lock-screen source checks passed. | Named active users, role matrix, leaver removal, owner recovery path and observed sensitive-action tests. |
| Catalog, tax and price | Item and import structures exist; no local tax acceptance was performed. | Representative item, unit, price, discount, tax and invoice cases approved for the jurisdiction and business. |
| Sales and exceptions | Sales call paths and receipt/report formatting checks passed. | Known normal sale, discount, void, return, reprint and correction cases tied to transaction IDs. |
| Stock and purchasing | Import-template structure and duplicate-record health checks passed. | Opening quantity, purchase receipt, sale movement, return, adjustment and physical-count reconciliation. |
| Reports and close | A bounded daily-report formatter was tested. | Day boundary, cash, digital tender, provider settlement, refunds, open items and manager sign-off for one known period. |
| Devices | No physical device was connected in this focused audit run. | Exact make, model, interface, driver and observed printer, scanner, drawer, scale or display result. |
| Payments | PCI SSC guidance is a buyer control, not Posnic payment evidence. | Provider responsibility, terminal inventory, configuration, tamper review, authorization, failure and settlement evidence. |
| Backup and recovery | A synthetic restore and backup-path tests exist. | Selected backup scope, off-machine copy, retention, restore drill, reconciled records, elapsed time and recovery decision. |
| Logs, updates and incidents | Log-path and update-setting tests passed. | Current logs, incident record, update result, failed-update path, escalation route and approved remediation closure. |
Practical workflow
Define the audit trigger
Run a review after a material release, staff or role change, device or payment change, unexplained variance, restore failure or incident. Set a recurring interval from business risk and change rate rather than copying a universal monthly promise.
Freeze the evidence period
Name the shop, till, release, timezone and transaction window. Preserve exports, receipts, provider records, screenshots and hashes before correcting anything that could change the result.
Use known cases, not random clicking
Prepare representative sales and exceptions with expected totals. Reconcile source transactions, printed or exported output, stock movement, cash and provider evidence before accepting the dashboard.
Separate software from external dependencies
A payment terminal, printer, scanner, operating system, network, tax rule and staff procedure can fail outside the Posnic code path. Give each dependency its own owner and acceptance evidence.
Close findings explicitly
Record severity, business impact, compensating control, owner, due date and retest result. An open high-risk finding cannot become a pass because the rest of the checklist is complete.
A seven-stage POS audit path
Keep the original evidence, the correction and the retest as separate records so an owner can see what changed.
Scope the review
Name the shop, counters, release, dependencies, period, owners and reason for the audit.
Preserve current state
Retain configuration, logs, exports, backup status and known totals before making changes.
Test access
Observe named roles attempting allowed and prohibited tasks, including recovery and support access.
Run known transactions
Execute representative sale, exception, stock, receipt, report and close cases with expected outcomes.
Exercise dependencies
Test selected devices, payment-provider paths, outage behavior and the actual fallback procedure.
Restore and reconcile
Restore a controlled copy, compare representative records and record elapsed time and data loss.
Assign and retest
Give each gap an owner and due date, preserve the correction, rerun the failed case and obtain approval.
Evidence and operating controls required
Hardware
- The exact till and operating-system build used for normal trade.
- Every selected printer, scanner, drawer, scale, display and payment terminal by make and model.
- A safe restore computer or isolated test environment that cannot overwrite production data.
- Off-machine storage for backups, exports, screenshots, hashes and approvals.
- The same network and power dependencies used during the representative shift.
Software and data
- Installed release, package hashes, update channel and dependency-review record.
- Named user and role matrix with joiner, mover, leaver and recovery decisions.
- Known catalog, tax, price, sale, exception, stock, payment and close test cases.
- Transaction, receipt, report, provider, log, backup and restore evidence with stable identifiers.
- A finding register with severity, owner, due date, correction, retest and approval fields.
Setup sequence
- Record the exact installed release, source reference, package hashes, operating system and review trigger.
- List every active user, role, support route and recovery method; confirm leavers and shared access explicitly.
- Choose representative items, taxes, prices, discounts and exception paths before testing.
- Run known sales, voids, returns, stock movements, receipts and reports with stable transaction IDs.
- Match cash and each digital tender to independent provider or settlement evidence.
- Test the exact physical devices and record model, interface, driver, configuration and result.
- Exercise one external-service failure and the actual operating fallback without assuming the whole till is offline.
- Create an off-machine backup and restore into a disposable environment before comparing representative records.
- Record every gap with severity, impact, compensating control, owner and due date.
- Rerun each failed case after correction and obtain named business approval before closing it.
What each person sees
Cashier or operator
Performs representative normal and exception tasks while an observer records the exact role, input, output and error.
Manager or accountant
Reconciles close totals, cash, provider settlement, refunds, stock and correction records for the frozen period.
Owner or technical reviewer
Accepts dependencies and residual risk only after failed cases have owners, evidence and a retest decision.
Mistakes to avoid
Avoid these during rollout
- Calling a source-test run or downloaded template a completed shop audit.
- Fixing records before preserving the original configuration, logs and totals.
- Testing only a normal cash sale and skipping discounts, voids, returns, split responsibility and failure paths.
- Treating payment, hardware, network, tax and staff controls as if the POS application owns all of them.
- Restoring over production data or accepting a backup without reconciling restored records.
- Closing a high-risk finding because another section passed.
- Using an unreleased source fix as proof that the installed stable package is remediated.
Keep a 24-control POS audit evidence record
The worksheet covers scope, release, dependencies, access, catalog, transactions, stock, reports, close, payments, devices, failure, backup, restore, logs, updates, export, staff observation and remediation. All observation, decision and follow-up fields start blank.
Primary sources used
Posnic v1.3.0 test source
The exact tagged source for the 15 focused files and the boundaries they actually exercise.
Posnic backup and recovery policy
Pinned documentation for backup contents, same-disk limitations, restore effects and recovery evidence that remains the shop's responsibility.
GitHub advisory GHSA-5p4m-2wfm-xmqj
The primary advisory record for the js-yaml denial-of-service finding present in the stable v1.3.0 dependency tree.
NIST small-business cybersecurity basics
Current guidance treats cybersecurity as continuous work and calls out access, updates, training, backups and backup testing.
PCI SSC payment-terminal scope
PCI SSC explains that payment devices are in the cardholder-data environment and that applicable controls depend on device and configuration.
PCI SSC terminal inspection controls
PCI SSC identifies device inventory, periodic tamper or substitution inspection and personnel awareness for applicable card-present devices.
GS1 retail POS implementation guideline
GS1's current guidance covers system and scanner capability, affected roles, controlled pilots, testing, feedback and quality assurance for retail barcode change.
Questions
What should a POS system audit include?
Include release and dependency identity, named access, representative sales and exceptions, stock movement, reports and close, devices, payment-provider evidence, backup restore, logs, updates, incidents and explicit finding closure.
How often should a POS audit be run?
Set the interval from business risk, transaction volume and change rate. Also run one after a material release, role change, device or provider change, unexplained variance, restore failure or incident. This page does not impose a universal monthly schedule.
Does passing source tests mean a shop passed its POS audit?
No. The 130 focused checks establish bounded source behavior at v1.3.0. They do not observe one shop's users, data, devices, payments, tax treatment, complete shift or recovery procedure.
Is Posnic v1.3.0 free of known dependency findings?
The reviewed stable lockfile was not finding-free. npm audit --omit=dev reported one high transitive js-yaml advisory through electron-updater. A later pinned source commit resolves js-yaml 4.3.1 and audited at zero production findings, but it was not a newer stable package in this review.
Does this checklist prove PCI DSS or tax compliance?
No. Applicability depends on the merchant, payment environment, jurisdiction and current requirements. Use the relevant assessor, acquirer, payment provider, accountant or qualified local adviser for the actual decision.
Can a backup be accepted without a restore test?
No. Record what was backed up, keep an off-machine copy, restore into a safe environment and reconcile representative records. The test method and frequency still depend on the business recovery requirement.
When is an audit finding closed?
Close it only after the correction or accepted compensating control is recorded, the failed case is rerun, the new evidence is retained and the named owner approves the residual risk.
Where Posnic fits
Posnic v1.3.0 has bounded source and synthetic evidence for local operation, access, reports, backup paths and update controls. It does not have an accepted customer-shop audit, complete trading day, physical-device set, payment settlement, tax result, independent security assessment or production recovery. The stable dependency finding also remains part of the reviewed release boundary.