A security client needs to know whether a patrol checkpoint was reached. A guard needs a reliable way to document the tour without feeling that an employer is silently tracking every movement, including off duty. A written GPS policy can reconcile those needs by defining a limited operational purpose, explaining what data is collected and when, setting access and retention rules, and warning managers not to treat a location signal as a complete account of a person's work.
Location data can be revealing even when a system is designed for checkpoints. The Federal Trade Commission's 2012 report, Protecting Consumer Privacy in an Era of Rapid Change, discusses Privacy by Design, transparency, and business practices for consumer data. It is not a statute governing employee monitoring, but its principles are useful design prompts: collect only what is needed for the stated service, explain the practice, and set a deliberate retention and access policy. State employment and privacy laws may impose additional requirements.
Define the purpose before choosing the technology
Start the policy with a clear statement of why location is used: for example, to verify that an assigned guard reached specified tour points during an assigned shift, support an investigation of a missed checkpoint, or provide a client with service-status information. Avoid broad language such as "for security and business purposes" that gives no meaningful boundary. If the company wants location data for another use, such as productivity scoring or discipline, assess that purpose separately and disclose it before relying on the data.
Write down what success looks like without claiming more than the system proves. A checkpoint event may support that a device was near a designated point at a reported time. It does not by itself establish that the assigned person carried the device, inspected the surrounding area, observed every hazard, or remained there for a prescribed duration. Managers should combine location events with shift assignment, guard report, supervisor review, and client evidence where appropriate.
Make a data map before writing the notice. Identify the device or source, which events are recorded, whether collection is continuous or checkpoint-based, whether background location is used, which vendors process the information, what appears in client reports, and what happens when the app is offline. If those answers are unknown, the employer is not ready to promise a narrow collection practice.
A policy should also distinguish service verification from employee evaluation. If location records may inform discipline, scheduling, or a customer dispute, explain that purpose and define the review before an incident occurs. A surprise secondary use can undermine worker trust and can lead managers to read a data point more confidently than the technology supports.
Limit collection to the assigned shift and checkpoint
A proportionate policy should distinguish an active tour from the rest of the day. If the operational need is checkpoint verification, configure location collection around the assigned shift and required event rather than gathering a continuous trail by default. Explain any exceptions, such as an emergency response or a documented investigation, and define who can authorize them. Avoid collecting location outside work time unless a specific, reviewed business and legal basis supports it.
State what the app records and what it does not. A worker should know whether the system captures a point when the employee submits a checkpoint, reads GPS in the background, stores the route between checkpoints, or uses another device signal. Do not say "we do not track you" if location is recorded at checkpoints; instead describe the event accurately and in plain language.
StockPoint is designed for per-building punch verification using photo and PIN evidence with GPS reported alongside honest accuracy context. A reading with a wide accuracy radius should be treated as less conclusive than a close, consistent event, not displayed as a false pinpoint. The system should help a supervisor understand the limits of evidence rather than invite a client to mistake an approximate signal for continuous surveillance.
Give workers clear notice and a usable exception path
Provide the policy before a worker is expected to use location-enabled guard-tour tools. Describe the purpose, collection window, data types, access roles, retention approach, and process for questions or corrections. Use a language and format that the workforce can understand, and explain how to request a copy or report that an event is inaccurate where the applicable law or company policy provides that route. A signature can confirm receipt; it does not replace the actual explanation.
Tell guards what to do when GPS is unavailable, a checkpoint tag is damaged, a phone battery fails, or the site has poor reception. A fallback should allow the worker to report the event by another documented method, with a supervisor review, rather than converting a technical problem into an automatic absence or disciplinary finding. Record which method was used and why.
A guard should also be able to explain an event that appears unusual. A worker may have been assigned to respond to an alarm, assist a visitor, or avoid an unsafe area. Preserve the initial event and attach the explanation and review rather than editing the route record to create a cleaner story. A fair process distinguishes a missed patrol from a legitimate diversion or a device failure.
Set access, client visibility, and retention limits
Name who can see raw location events and who can see only a service summary. Supervisors may need route-level details for an operational review; a client may need confirmation that a checkpoint was completed or an exception remains open. A client does not ordinarily need unrelated worker travel history, a private phone identifier, or payroll details to confirm service. Use role-based access and review permissions when a contract, site, or supervisor changes.
Choose a retention period based on the purpose, contract, applicable legal obligations, claims, and a documented risk review. Keep detailed location traces only as long as they are useful or required; retain a narrower service record if the customer needs proof of contract performance after raw data is no longer needed. The FTC's privacy report frames retention and minimization as privacy-by-design practices, not a universal employee-data deadline.
Document how legal holds and investigations suspend ordinary deletion, who approves an exception, and when the hold ends. A retention schedule that says "keep forever" is not a schedule. Conversely, deleting a record under a routine setting after a complaint or claim has arisen can create a separate problem. Involve counsel when a dispute, regulatory inquiry, or preservation obligation is reasonably anticipated.
Separate checkpoint evidence from performance judgments
A location event is one input, not an automatic score. Before treating a late or missing checkpoint as misconduct, compare the assigned route, shift start, device accuracy, connectivity, approved detour, incident log, and the guard's explanation. A location platform may be wrong, delayed, or associated with a device rather than the worker. A disciplinary conclusion should be based on a fair review of relevant evidence and the employee's opportunity to respond.
The same caution applies to client reporting. A portal status should distinguish completed, overdue, and under review rather than showing a misleading binary indicator when information is incomplete. Do not publish precise coordinates or a worker's live path to a client when a building-level status is sufficient. Explain any limitation in the service agreement so the portal's display is not mistaken for a guarantee of patrol quality.
StockPoint's client portal can show live checkpoint status and proof-of-work records while keeping the location context tied to a specific building event. An operations team can use the audit trail to identify who reviewed a missed checkpoint and what evidence informed the decision. The technology supports a controlled process; it does not replace the employer's responsibility to apply policy consistently.
Worked example: a checkpoint appears outside the geofence
Assume the evening supervisor sees that a guard's checkpoint appears just outside the configured radius. The dashboard shows a GPS accuracy estimate of 45 meters, the building entrance is near a covered loading bay, and the guard's shift report notes that an alarm response diverted the route. Those values are illustrative. The first step is not to infer that the guard skipped the patrol; it is to inspect the event's stated accuracy, the location layout, dispatch activity, and the report.
The supervisor records the review, asks the guard to explain the sequence, and checks whether the alarm response was authorized. If the guard reached the checkpoint but the device's reading was imprecise, the record can note that conclusion and retain the original point. If the guard did not reach it, the record can explain the actual reason and any client notification. The system should preserve both the sensor result and the human decision.
The customer may need to know that one tour event is under review and when the site was secured. It does not need an employee's unrelated location history. A narrow status message, supported by an audit-logged supervisor review, is more useful than sending a raw GPS trace that might be misunderstood.
Review vendors and the policy over time
Before adopting a platform, ask what data it receives, how it handles permissions, whether workers use personal or employer devices, how exports and deletion work, and which subprocessors may receive information. Put limits and responsibilities in vendor terms. Test the configured experience with a real route and confirm that the client sees only the agreed service record, not internal notes or information about other customers.
Review the policy when the company changes technology, starts continuous collection, serves a new jurisdiction, changes the client portal, or uses location data for a new decision. Train dispatchers and account managers not to promise perfect accuracy or say that a location event proves a person performed a full inspection. Provide a route for workers to raise concerns without losing access to the safety process.
For a practical starting point, StockPoint's operations features connect checkpoint status with a documented building-level work event instead of requiring a general-purpose tracking feed. Visit getstockpoint.com to sign up for StockPoint and give security and field-service teams bilingual workforce tools, controlled client visibility, and audit-logged review of exceptions.