IT needs to understand what your mapping software would contain and who would use it. A map of public store locations raises different questions from one containing customer addresses or employee home locations, even if both use the same software.
For a Maptive review, the proposed use gives those questions their context. The reviewer needs to understand the work the map supports, the records behind it and the people who would get access. The reviewer needs that description to judge whether the software fits your company's security rules.
| Review requirement | Public or documented evidence | Evidence still needed |
|---|---|---|
| Identity | Vendor statements list single sign-on and multifactor authentication | Supported providers, enforcement and account availability |
| Team access | Team Map Share documents editing and view-only access | Tests of the proposed roles and account arrangement |
| External sharing | Public and Password Protected viewing are documented | Approved recipients, data exposure and release tests |
| Encryption and hosting | Vendor publishes security and storage statements | Exact mechanisms, regions and contractual commitments |
| Audit and retention | Vendor statements list audit logging | Events, access, export, retention and deletion details |
Define the mapping setup for IT
Give the reviewer a concrete description of the job. Say who will create maps, which fields they need, who will view them and whether anyone outside the company will receive access. Include the source of the data and the person who will keep it up to date.
Reduce the file to the fields the map needs before the review. A branch-coverage map may need an address, customer ID and service category without needing names or contact details. Removing fields you don't need gives the setup less data to protect. It also makes the planned use easier to judge.
Addresses can still be sensitive when they identify people or private activities. Tell IT what the locations represent. A field called Location is less useful to the reviewer than an explanation that it has employee home addresses or business sites listed for anyone to see.
State how long the data is needed and what should happen when the project ends. Include exports and shared copies in that plan. Ask whether an aggregate map would serve the audience better than a detailed location map. If you create a separate file of area totals, review it for details that could identify someone.
Use a non-sensitive sample for account and sharing tests. Give it the same column structure as the proposed file, including fields you plan to keep private. This lets you check what the viewer can see and do before putting real records into it.
Gather the vendor evidence
Confirm identity and account controls
Maptive's public security material lists single sign-on, multifactor authentication, roles and audit logging. Ask how the identity controls work for the account you intend to buy or use. Ask which identity providers are supported and whether those controls are available in your plan. Find out whether you can require everyone who needs access to use them.
Give the reviewer written answers rather than assuming that a listed feature is active by default. Ask how account access changes when someone leaves the team and who will be responsible for managing the account. The person who manages the map may have a different job from the person who manages user access.
Maptive also states that it has passed a Salesforce AppExchange security review. Ask for evidence of that review and what it covered if the claim matters to your decision. A vendor statement about one review doesn't establish that every requirement for your setup has been met.
Keep the dates of the answers and the account settings they cover. A response for a different plan or setup can leave a requirement unanswered even when it sounds reassuring.
Clarify encryption and hosting
Ask for the mechanisms used to protect data in transit and at rest. Maptive's public material uses SSL language in discussing both transfer and storage. Get a separate explanation of storage encryption before recording the at-rest control. Terms about moving data alone don't explain how stored data is encrypted.
Request the storage region available for your setup, the services that handle the data and the contractual commitments that apply. Maptive has a public list of options for where data can be stored. Confirm the actual arrangement your account would use, including any requirements your company has for where the data is processed.
Include backups and recovery in the questions. Ask what happens to uploaded data and copies after deletion, and which commitments are included in the agreement. Keep promises separate from controls you've seen working in your account.
Your review may require a SOC 2 report, an ISO 27001 certificate or a penetration-test summary. You may also need a specific agreement for regulated data. If any of these are required, ask for that evidence directly. The public security statements don't establish those items. Let the reviewer check what any supplied document covers and how old the evidence is.
Document audit and retention requirements
State which events your team needs to check. These could include login activity, data changes or sharing changes. Since Maptive publicly lists audit logging, ask which events are recorded, who can access the records and whether they can be exported for your review process.
Ask how long the vendor keeps logs and uploaded data. Request answers about deletion, subprocessors, incident notice and recovery that match the proposed use. Get written answers to these questions. Clicking through the map won't tell you how the vendor handles all copies of your data.
A requirement sheet can use Yes, No and Partial answers with an explanation and supporting document. For Partial, say which part is covered and which part remains open. Record who will get the missing evidence rather than letting a vague answer become an accepted control.
Test Maptive's documented access paths
Verify licensed team permissions
On the home screen, open the map's three-dot menu and select Team Map Share. Choose each team member and give them editing or view-only access. This team arrangement requires more than one license, bought together, so confirm that the intended accounts belong to the right arrangement before testing.
Use separate sample accounts for the roles. Have the editor try the map and data changes needed for the job. Have the viewer try the reading tasks the team expects them to perform, then check whether they can make a permanent change. Record the account, role, action and observed result.
Only one user can edit the map at a time. Include that condition in the operating plan. A team-access test can confirm the proposed workflow without pretending several editors can change the shared map at the same time.
Verify the external viewer experience
Open the sample map, select Share and then Share Externally. Choose Password Protected or Public, set the starting view, and copy the map link. Open it while logged out so the test reflects what an external recipient can do.
Public allows anyone with the link to view the map. Assume recipients can forward the link. Password Protected uses a common map password shared by the recipients. It doesn't identify each person, so compare that access method with your company's recipient requirements.
Check the starting view and what the viewer can do. Unlicensed external viewers don't need to log in and can't make permanent changes to the map. They may still be able to inspect data or use tools that the owner has allowed. Review what that access lets them do.
Change the test password and try the old password again. The documentation says people using the old password are locked out. Record what you observed in the sample release, including the test date and settings.
Check the data in the shared view
Click through marker popups, available tools and any permitted exports. Look for fields the viewer should not receive. An address field might be necessary for the map's purpose while the recipient doesn't need another column in the same record.
Test beyond the first screen. A starting view can be narrow while the viewer has ways to explore other locations. A filter used to present one region should not be treated as proof that all other records can't be accessed. Check what the viewer can do using the logged-out view.
Review an exported file when exports are permitted. Check its columns and rows against the intended release, rather than assuming it contains only the fields currently visible on the map. Save the observed results and screenshots with the tested settings.
If the audience needs only area totals, test a separate summary map built from those totals. This gives you a smaller release to review. Check the summary's contents too, since a small group or detailed geography can still reveal more than the audience needs.
Close out the test access using the right process for the account, and change the shared test password where applicable. Record the cleanup so the test map doesn't become an extra copy that nobody manages.
Send the evidence for a decision
Mapping software passes a security review when its controls and evidence meet your company's requirements for the proposed use.
Put the description of the setup, requirement sheet, vendor answers and access-test records together. Include the proposed account arrangement, sharing settings and agreements. Make it easy for the reviewer to find the evidence for a requirement without reading every vendor page.
List unresolved items with the question, the person who will answer it and the next piece of evidence needed. If you still don't know how identity controls are enforced, get an answer about the settings. If you still don't know how long data is kept, get the written handling and deletion terms. A passing access test cannot answer either question by itself.
Ask for a decision on this defined setup. Keep any approved conditions with the operating instructions, including the data fields, users and sharing scope covered. When those change, the team can tell the reviewer exactly what needs to be reviewed again.
