Most superintendents don't lie awake worrying about their schedule getting hacked. And honestly, a three-week look-ahead isn't the crown jewels. But schedule data leaks more than people think — who's on site when, which trades are behind, what your real float looks like, and sometimes cost-loaded activities that tell a competitor exactly how you priced the job. I've watched a sub walk into a coordination meeting already knowing our sequencing was slipping because someone forwarded a PDF to the wrong distribution list. Nobody got hacked. Somebody just shared too much.
So when you're picking software to run your weekly work plans and rolling look-aheads, security isn't a box on a procurement checklist you tick and forget. It's mostly about controlling who sees what, keeping the field side sane, and making sure the vendor isn't a liability. Here's how a working super should think about it — without turning into your IT department.
Know what's actually sensitive before you protect it
Not all schedule data is equal. If you treat every field like a state secret you'll make the tool so locked down nobody uses it, and an unused schedule is worse than an insecure one. Sort it into rough tiers:
- Genuinely sensitive: cost-loaded durations, margin assumptions baked into activity pricing, labor rates, anything that reveals your bid strategy. This is the stuff that hurts if a competitor or an owner's rep sees it.
- Contractually loaded: commitment records, PPC (percent plan complete) history, variance reasons, and who was assigned what when a milestone slipped. This is boring right up until there's a claim, and then it's evidence. Whoever can edit it can rewrite history.
- Operationally useful but low-risk: the sequence of who works where next week. You generally want subs to see this. The failure here isn't exposure, it's showing them so much detail they get confused or spooked by float you'd rather keep to yourself.
- Personnel data: crew names, phone numbers, sometimes badge or certification info. This one carries actual privacy obligations, especially on public and prevailing-wage work.
Once you know which fields sit in which tier, the rest of the security conversation gets a lot simpler. You're not protecting "the schedule." You're protecting maybe three or four data types, and each has an obvious answer.
Access control is the whole game
Ninety percent of real-world schedule leaks aren't attacks. They're the wrong person having the wrong level of access, or an old login that never got shut off. Get this right and you've handled most of your risk.
What to insist on when you evaluate a tool:
- Role-based access, not all-or-nothing. A crew leader should see their assignments and mark work done. A sub should see the trades and areas that concern them. A PM sees cost. A super sees everything. If the software only offers "admin" and "viewer," that's a red flag — you'll end up handing out admin because you need one person to do one extra thing, and now half the job can rewrite the plan.
- Project-level scoping. Someone running the parking structure shouldn't automatically see the schedule for the job across town. Access should be granted per project, not per account.
- Field vs. office separation. The value of a mobile companion app for crew leaders is that they can see their week and report progress. That's a deliberately narrow slice. A crew leader's phone should never be a window into cost loading or the master sequence for trades that aren't theirs.
Tools like LookAheadWall are built around location-based weekly plans and trade-flow sequences precisely so you can share the plan without exposing the strategy — a sub sees their pull and their area, not your margins. That separation is the feature that matters most for security, even though nobody markets it that way.
The subcontractor access trap
This is where good intentions cause the most damage. You want subs bought into the plan, so you give them a login. Six months later that drywall sub is off the job, working for your competitor, and their account still works. Nobody remembered to kill it because killing access isn't anybody's job until it's a problem.
Handle sub access with three habits:
- Give them the minimum useful view. They need their scope, their areas, their dates, and the handoffs immediately around them — the trade before them and the trade after. They do not need the full rolling look-ahead for the whole building, and they definitely don't need cost.
- Make offboarding a closeout item. Put "revoke sub access" on the same list as final billing and retention release. If it's not on a checklist, it won't happen. When a sub demobilizes, their login dies that week.
- Prefer per-user sub logins over a shared password. The second a sub's whole crew shares one login taped inside a gang box, you've lost any ability to know who changed what — and you can't revoke one person without locking out the whole trade.
What to actually ask a vendor
You don't need to be a security auditor. You need to ask a handful of questions and listen for whether the answers are specific or hand-wavy.
- Is my data encrypted in transit and at rest? "In transit" (HTTPS) is table stakes; anyone serious has it. "At rest" means it's encrypted on their servers too. You want both.
- Do you support multi-factor authentication? A stolen or reused password is the single most common way accounts get popped. If the office side can turn on MFA — even just for admins and PMs — you've closed the biggest door.
- Who owns my data, and can I export it? Read this in the contract, not the sales deck. You want a clear statement that the data is yours and a real export path (not a screenshot). If the vendor folds or you switch tools, your commitment history and PPC records need to come with you.
- Do you keep an audit trail of changes? Change tracking with user attribution — who moved that milestone, who marked that task complete — is worth more for dispute defense than any firewall. On a contested delay, "the system shows the sub confirmed the date and then didn't perform" is a strong position.
- What's your track record and do you have SOC 2 or similar? A formal certification is nice on enterprise work and sometimes required by owners. On smaller jobs, it's fine if a vendor doesn't have the paperwork — but they should still give you straight answers about backups, hosting, and what happens in an incident.
If a salesperson gets vague or defensive when you ask where the data lives and whether you can get it back, that tells you more than any certificate would.
The field side is where security actually breaks
Enterprise buyers obsess over data centers. On a jobsite, the real exposure is a phone left on the tailgate and a login that's shared around the trailer. Practical field rules that actually move the needle:
- Lean on the phone's own lock screen. Any decent mobile app inherits the device passcode and Face ID / Touch ID. The single best thing you can tell a crew leader is to lock their phone. A lost, unlocked phone is the whole breach.
- Sessions should time out. A shared field tablet that stays logged in forever is a problem the day it walks off. Look for a tool where sessions expire and remote sign-out is possible.
- Kill the "one login for the whole crew" habit. It feels efficient. It destroys accountability and makes offboarding impossible. Individual logins are worth the mild hassle.
- Watch what gets forwarded. The most common leak isn't the software at all — it's a screenshot or exported PDF texted to someone who wasn't supposed to have it. No permission system protects against a super forwarding the whole cost-loaded plan to a sub because it was faster than filtering it. That's a discipline problem, and it's on you, not the vendor.
Cloud, backups, and the boring stuff that saves the job
The security question people ask about the cloud is "can someone break in?" The question that actually bites you is "what happens when I need last month's plan back?" Data loss is a far more common disaster than data theft.
So make sure the vendor backs up regularly and — this is the part people skip — has actually tested restoring from those backups. A backup nobody has restored is a rumor. Also understand geography: on some public and government work, there are rules about where data can be hosted. Ask, don't assume.
And keep your own lifeline. Periodically export the schedule and PPC history to something you control. Not because you distrust the vendor, but because your commitment records and variance history are contract-relevant documents, and you never want your evidence trapped inside a subscription you might not renew.
A short implementation routine
You don't need a security program. You need a few habits baked into how you stand up and run the tool:
- At setup, decide your roles before you invite anyone. Draw the line between field and office, and between "sees cost" and "doesn't."
- When you invite, give each person the narrowest role that lets them do their job. It's easy to add access later; it's awkward to claw it back.
- Turn on MFA for anyone who can see cost or edit the master plan.
- Every month or two, glance at the user list and pull anyone who's off the job. Make it part of your regular schedule-update rhythm, not a special event.
- At closeout, revoke sub access and export a clean copy of the final schedule and PPC history for the project file.
Bottom line
Schedule security isn't about paranoia, and it isn't about buying the tool with the longest list of certifications. It's about controlling who sees what, killing access when people leave, keeping the field simple, and picking a vendor who gives you straight answers and lets you take your data with you.
Do those few things and you've handled the risk that actually shows up on real projects. Skip them, and the leak won't come from a hacker — it'll come from an old login nobody closed and a PDF that got forwarded one address too far. Protect the handful of fields that matter, keep the plan usable, and get back to building.