Security at InOutBoard

Encryption

In transit. Everything you and your people send to InOutBoard travels over HTTPS. Plain HTTP requests to our sites are permanently redirected to HTTPS, and every response carries an HTTP Strict Transport Security header with a one-year lifetime—so after a browser has visited us once, it refuses to make an unencrypted connection to that site at all. The application and admin sites extend that policy to their subdomains. Connections we make outward to our payment processor are pinned to TLS 1.2.

At rest. Your data sits in Azure SQL Database and, for profile photos, Azure Blob Storage. Both are encrypted on disk by Microsoft using AES-256—Transparent Data Encryption for the database, Storage Service Encryption for photos.

Passwords and signing in

Passwords are stored as a one-way hash, never as text we could read back. We use PBKDF2 with HMAC-SHA512 at 210,000 iterations and a random salt generated per password—in the range OWASP's Password Storage Cheat Sheet has recommended for that algorithm. Each stored hash records the algorithm and iteration count that produced it, so when we raise the cost, existing accounts upgrade quietly the next time their owner signs in.

New passwords must be at least 12 characters and contain at least one number and one letter, checked on the server so the rule cannot be skipped by posting the form directly. Like NIST SP 800-63B, we favor length over mandatory symbols or forced periodic changes—the approach that measurably resists guessing instead of encouraging predictable substitutions. If a password is forgotten, we send a single-use reset link to the address on the account. The code in that link is 128 bits from a cryptographic random number generator, it expires after 24 hours (7 days for a new-account invitation), and both the code and its expiry are re-checked on every request—not just when the page first loads. We never send a password by email, because we do not have one to send.

Guessing attacks. Two independent counters run before any password is checked:

• Per account—repeated failures lock the account, with thresholds that follow PCI DSS v4.0 Requirement 8.3.4 (lock after no more than 10 attempts, for at least 30 minutes).
• Per network address—an independent counter blocks any source that fails across many accounts, so one machine cannot grind through a list of usernames.

Google reCAPTCHA Enterprise scores every sign-in and signup, and repeated failures escalate to a visible challenge. A sign-in attempt against a username that does not exist costs the server the same work as a real one, so the login page cannot be used to discover which email addresses have accounts.

What we hold, and what we don't

We hold what the product needs: names, work contact details and location, status entries and their history, calendar events, resource bookings, messages sent through the status board, and an optional profile photo.

We do not hold card numbers. When you enter a card, your browser sends it straight to Authorize.Net, which returns a one-time token; our servers receive only that token, never the card number or security code, and Authorize.Net keeps the card for future charges. Nothing about that card is written to our database except the type, the expiration date, and the last four digits—enough to show you which card is on file, and nothing that could be used to charge it elsewhere. The full number and the security code (CVV/CVC) are never written to our database. This payment path is what our annual PCI DSS validation and quarterly scanning cover.

Who can see your data

Inside your organization. Administrators you nominate control who has an account, who can change settings, and who is removed. Everything else follows from that.

Our support team. Diagnosing a problem sometimes means seeing what you see. We only sign in to your account after you have asked us for help—an InOutBoard administrator then issues a sign-in token from our internal tool. That token is single-use and short-lived, and only a SHA-256 hash of it is written to the database—so reading our own table yields nothing anyone could redeem. Every issue and every redemption is recorded with the staff member responsible, the account entered, the timestamps, and the originating IP addresses. Those records are kept for 90 days as an audit trail. If you would like the entries for your account from that period, ask us.

Keeping and deleting data

Deleting a user hides them immediately but keeps the record recoverable for a grace period, because in practice most deletions we are asked to reverse are reversed within days. After that window—180 days by default—the user and everything that references them is permanently removed: status history, calendar entries, bookings, messages, and photos. That purge is irreversible by design.

Status history is kept for three years. Each entry is deleted automatically three years after it ends, for every account, so the reports cover the most recent three years. Resource status history, calendar entries and resource bookings follow the same rule, and each message is deleted three years after it was sent. If you need history for longer, export it to CSV on your own schedule.

Your data stays yours while you are with us. Every report in the product exports to CSV, so you can take a copy at any time without asking. Closing your account is a separate matter from deleting a user: a canceled account is automatically purged three years after cancellation. If you would like it removed sooner, tell us and we can do it before that three-year mark.

How the software is built

InOutBoard is three separate sites sharing this security posture rather than one codebase: the application at app.inoutboard.com, where your data lives; an internal admin site staff use to operate the service; and this marketing site, which never holds your data. The controls below are named against the one they apply to.

• Application. Database access goes mainly through an ORM with parameterized commands, and where a query is built as text, the values in it are escaped. Both are there so that user input is treated as data, not run as SQL.
• Application. Form state is signed with HMAC-SHA256 and bound to the signed-in user, so a page's hidden state cannot be tampered with between the browser and the server, or captured from one session and replayed against another account.
• Application. CSV exports neutralize spreadsheet formula injection: a cell that begins with a formula character is prefixed so Excel and Google Sheets treat it as text, and a value someone typed into the product cannot execute when your export is opened.
• This marketing site enforces a strict Content Security Policy and sends X-Frame-Options: DENY, X-Content-Type-Options: nosniff, a referrer policy, and a permissions policy. Its contact form is protected by a double-submit-cookie antiforgery token and a honeypot field.
• All three sites suppress server version headers, and their error pages never expose internal detail to a visitor.

Sub-processors

These are the third parties that may handle customer data on our behalf. We keep this list current.

PCI DSS

We validate our PCI DSS compliance every year and hold a current Attestation of Compliance. Our self-assessment is completed annually with SecurityMetrics, and we can send the attestation to your compliance team on request.

Alongside it, SecurityMetrics scans our public-facing systems every quarter as a PCI SSC Approved Scanning Vendor—the category of vendor authorized to perform the external vulnerability scanning required by PCI DSS Requirement 11.3.2. The automated scans probe production for known vulnerabilities, missing patches, weak TLS configuration, and exposed services, on a schedule set by the standard rather than by us. We have passed every scan.

Between the two, our security is checked from the outside all year round: compliance attested annually, systems re-tested every quarter, both by an independent firm whose certificate you can verify above without taking our word for anything.

Your security review

We make vendor review easy. We will answer any question directly, send our current Attestation of Compliance to your compliance team, and complete your vendor security questionnaire line by line— get in touch and tell us what you need. Most reviews find their answers on this page, which makes the rest a quick turnaround.

For how we handle personal data as a matter of policy, see our Privacy Statement and Terms of Service.

Reporting a vulnerability

If you have found a security problem in InOutBoard, please tell us at support@inoutboard.com. Include what you did, what happened, and anything we need to reproduce it. We read every report and we will tell you what we find.

Please test only against your own account or a trial account, and do not access, change, or retain another customer's data while investigating. We will not pursue anyone who reports a genuine issue in good faith and gives us a reasonable chance to fix it before going public.