PRIMARY SOURCEBAM’s own privacy policy and the settings of its own store system, both public
When you hand a store your name, address, phone number, and card number, its privacy policy is the promise it makes about who inside the company is allowed to see that information. Bricks & Minifigs makes that promise in writing, in a policy still posted on its website today, and it is not vague: it says only the employees who need your information, for billing or customer service, are allowed near it. This post sets that specific promise beside a second public record, the configuration of BAM’s own central store system, which can be read without logging in. The two do not line up. The setting that would keep the promise, the one that limits who inside the company can see your data, is switched off.
Why this belongs on this site. This site reads BAM’s own records against themselves. Both halves here are BAM’s own and both are public: the privacy policy is published for every customer, and the settings described below are served by BAM’s own system to anyone who opens the page, with no password required. Nothing here is a leak, and nothing here describes a break-in. It is one public promise, read next to the public settings that were supposed to keep it.
BAM’s privacy policy, under the heading “Security,” makes two representations to customers. It is the policy currently posted at bricksandminifigs.com; it carries a “Last Modified” date of May 28, 2019, which is to say it is the operative policy the company still stands behind today. The two sentences that matter read:
“Wherever we collect sensitive information, that information is encrypted and transmitted to us in a secure way. … Only employees who need the information to perform a specific job (for example, billing or customer service) are granted access to personally identifiable information.”
Read the second sentence closely, because it is specific. It does not say access is handled carefully. It names the narrow jobs allowed near your data, billing or customer service, and promises everyone else is shut out. That is a concrete promise of what security people call access control. The same policy lists what is being protected: your name, address, email, phone number, and “credit card number, expiration date … used for billing purposes and to fill your orders.”
BAM runs its stores on a single central system it calls Patron. Like many web systems, Patron decides which of its features are on with a board of named switches, and it publishes the current state of that board to the browser, no password required. Three of those switches decide whether the promise above is kept, and all three read the same way.
The switch for role-based access, the setting that would limit each employee to only the data their job needs, reads off. The switch for a second sign-in step beyond a password reads off. And the page an administrator would use to give different employees different access is turned off as well, so there is not even a screen on which to build the need-to-know limit the policy describes. All three read off in the company’s test system and in the live one that runs the stores. In the words of the record that captured them, “every Patron user has the same access level.” That is the plain contradiction: the policy promises access is confined to billing and customer-service roles; the setting says everyone holds the same keys. And the code for the second sign-in step is present in the system and switched off, so this is a protection that was built and then turned off, not one that was never made.
This is not a switchboard nobody tends. The same board that leaves the two data protections off is actively worked: on it, the company has turned on inventory scanning, LEGO pre-orders, purchase-order tools, marketing dashboards, point-of-sale syncing, sales-data webhooks, and a new dashboard. Someone goes to this board and decides what to enable, feature by feature. Of everything on it, the two switches that guard who can see a customer’s personal information, and the page for setting them up, are the ones left in the off position.
Two things should be kept apart, because the honest version matters. Some of BAM’s system answers with no login at all, but what it hands back there is operational data about the stores and the names of staff, not customers’ personal records. The customer records, the rewards signups with name, email, phone, address and birthday, and years of purchase history, sit behind the login. The point is not that customer data is lying in the open. It is that the door in front of it is held by a single password, with the second sign-in step switched off, and behind that door the need-to-know partition the policy promises is switched off too, so a single account reaches the same records as any other. Encryption in transit, the first thing the policy promises, is a real and separate protection, and it does not answer the second promise at all. Locking the front gate is not the same as keeping the promise about who, once inside, is allowed into which room.
This is not a report of a break-in. No breach of BAM’s system is known, and nothing here predicts one. The obligation a promise like this raises is a different and older one: the duty to keep personal data reasonably secure, and the rule against telling customers you have protections you have switched off. The Federal Trade Commission treats an unreasonable data-security practice as an unfair one, and a security promise a company does not keep as a deceptive one. Utah, where BAM is headquartered, requires any business holding personal information to maintain reasonable procedures to protect it. Oregon, where the stores at the center of this story sit, imposes the same affirmative duty to develop and maintain reasonable safeguards. Each is a standing obligation, and none of them waits for a breach: the distance between the promise and the setting is the thing itself.
The fair counterpoint. No breach of BAM’s data is known, and this site does not claim one or predict one; a switch set to off is not evidence that anyone’s information was taken. Feature flags are changed all the time, and it is possible the settings differ from what BAM runs on a given day, though the capture recorded the same values in both its test and live environments. A very small company with a handful of trusted employees may have practical reasons that everyone shares one access level, and that arrangement is not itself unlawful; the tension is with the specific promise the policy makes, not with the arrangement in the abstract. The policy’s encryption-in-transit representation appears to be met and is a genuine protection as far as it goes. The policy is dated 2019 and BAM is free to update it at any time; if it does, that is easy to check, and a customer can read the version posted today. The legal description above is general: data-security duties and their remedies vary by state and by facts, most carry no automatic payout to any individual, and nothing here is legal advice. This site is not neutral about BAM and says so; both records quoted here are BAM’s own and public, so a reader can check each one. Nothing here is a finding of law, and everyone named is presumed to have acted lawfully.
Sources. The promise is quoted from the “Security” section of the Bricks & Minifigs privacy policy, posted at bricksandminifigs.com/privacy-policy/ and verified live on August 1, 2026 (marked “Last Modified: May 28, 2019”); an archived copy captured July 21, 2026 is byte-identical. The settings are BAM’s own feature-flag values as served, without authentication, by its Patron store-management system and recorded in an endpoint capture on July 23, 2026: the flags controlling role-based access control, two-factor authentication, and the user access-control page all evaluate to false in the staging and production environments, while the same flag set shows features such as inventory management, the minifigure scanner, LEGO pre-orders, purchase orders, marketing dashboards, point-of-sale syncing, and webhooks evaluating to true; the capture records that “every Patron user has the same access level” and that the two-factor code exists in the system but is disabled. To avoid describing any method of access, this post does not reproduce the system identifiers, addresses, or paths in that capture. On the law: the Federal Trade Commission Act, 15 U.S.C. 45, reaches unfair data-security practices (FTC v. Wyndham Worldwide Corp., 799 F.3d 236 (3d Cir. 2015)) and deceptive security representations (the LabMD and In re Uber lines); the Utah Protection of Personal Information Act, Utah Code 13-44-201, and the Oregon Consumer Information Protection Act, ORS 646A.622, each impose an affirmative reasonable-security duty independent of any breach. This site’s earlier reading of the same store system appears on the store map and the support portal; a related look at children’s data is here.
The BAM Map is independent reporting on matters of public concern. Nothing here is a finding of any person’s guilt; the criminal charges referenced are unadjudicated and every defendant is presumed innocent. Sources are linked so readers can check the record. · Home · Map · The law · Bodycam