Did You Know?

Most network maps are static snapshots. Social System Maps evolve over time—just like the people and relationships they represent.

Test drive or log into sumApp(opens in a new tab)

Managing Project and Member Privacy

Estimated reading: 5 minutes 77 views Contributors

Privacy in a Social System Map is a particular kind of trust. People aren’t just handing you a name and an email — they’re showing you who they’re connected to and how they relate, and that’s tender information.

Two things shape how you hold it. First, privacy here isn’t one switch you flip. It’s a handful of choices living at different layers — some yours as the account holder, some the member’s, some decided by where the data travels. Second, there’s no single right configuration. Some Social System Maps are built to be fully public, on purpose and for the long haul — openness is the whole point. Others carry information sensitive enough that data security is a genuine concern.

Most live somewhere in between. So the task isn’t to lock everything down, or to throw everything open. It’s to fit the privacy of the map to its purpose — and to the people who trusted you with their connections.

What follows walks those layers, so you can see what’s protected where, and choose well for your map — not someone else’s.

Account Data

sumApp holds two kinds of data, and it’s worth keeping them separate.


Account data is about the account holder — account settings, details, login, projects owned. It’s the data of the person who set up and pays for the account.

Project data (or member data) is everything gathered inside a project about the people in it: their bios, survey answers, the connections they name, the preferences they set. It’s the data of the people being mapped.
Privacy lives almost entirely on the project side. The account data is a straightforward customer relationship; project data you’re holding on someone else’s behalf — and nearly every choice below is about how to steward it.

Our Policies

A few promises, on both sides of that line:
Your account data. We’ll email you about sumApp updates — that’s the only reason we’ll reach out. We never sell account data, and never use it for anything beyond sumApp.
Your members’ data. Greater Than The Sum never emails map members, for any reason (unless they reach out to us first). And we only ever access a project’s data to help you troubleshoot.
For the formal details, see our full Privacy Policy

Project (Member) & Map Data

sumApp and Kumu do different jobs.

sumApp is where the data is gathered and lives — everything your members enter. Kumu is where that data is visualized, and where the map is accessed.

The two are joined by a JSON file. The data is stored in sumApp; the JSON is the conduit that carries it into Kumu to be drawn as a map.

Because your members’ data lives in sumApp and is shown through Kumu, protecting it means understanding how privacy works in each.

They guard different things, in different ways.

Privacy in Kumu

Kumu has privacy settings of its own, at two levels.

At the map level, a map is either public or private (this follows Kumu’s free vs. paid plans). A public map is findable and viewable by anyone. A private map is neither — it can only be reached via Kumu account permissions or through an embed link.

At the field level, Kumu offers private fields and relevance settings that control whether a field shows in the side panel, and who has permission to see it.

But this is important: none of Kumu’s privacy settings actually keep any field un-findable from anyone who can view the map. In the normal setup — a private Kumu map embedded into sumApp — anyone who can see the map can reach everything in the JSON file behind it. It takes only an easy, well-known move (opening the browser’s developer console) to read the raw data. When the data is being imported from somewhere else, “Hidden” in Kumu means hidden from the casual eye, not secured.

Most of the time, that’s fine: if someone can reach your map through sumApp, you generally want them to have the member information anyway. (The one deliberate exception — the email addresses sumApp uses to invite members are never written into the JSON, kept out precisely because the JSON is readable.)

When something is more sensitive than that, Kumu isn’t where you protect it. That’s what sumApp’s layered protections are for — which is where we head next.

Functionality-based protections within sumApp

Because the data lives in sumApp, it can be protected before it ever reaches the map.

sumApp offers four layers of protection — here’s what each one does:

The Membership Layer – Terms of Agreement — Require everyone entering your project to agree to a statement — a confidentiality pledge, say — before they can reach the survey or the map. No agreement, no entry.

The Individual Layer – My Preferences — Let each member, and you as admin, control their own presence: whether they’re visible to others on the connections tab, exportable to the map, or removed from the project altogether.

The Survey Question Layer – Protected Fields — Hold a sensitive field out of the map entirely — a demographic question people won’t answer honestly if it’s public or an old question you’ve retired. A protected field stays in sumApp and never enters the JSON, so no one viewing the map can reach it.

The Start-Over Layer – Resetting the Project JSON URL — Regenerate the JSON link itself, so anyone who had the old one — a former collaborator for instance — can no longer reach your data. The last resort when the project-data JSON link has ended up where you don’t want it to.

Related Articles

Managing Project and Member Privacy - PreviousTurning Data-Flows Into a PracticeNext - Managing Project and Member PrivacyTerms of Agreement

Leave a Comment

Share this Doc

Managing Project and Member Privacy

Or copy link

CONTENTS