- Audience
- Administrators and senior reviewers managing inter-organization trust.
- Read first
- Policy thresholds — they control who can act here.
- Companion
- Visibility choices for how trust shows up in reports.
- Outcome
- Stable partner connections, tracked documents, and useful trust groups.
Purpose
Trusted partners are organizations your team intends to coordinate with. Castlewatch treats the relationship as a workflow: one side requests, the receiving side reviews, document status is tracked, and the relationship is accepted, declined, connected, or revoked. This keeps incident visibility tied to real operational trust instead of informal contact lists.
Use trusted partners for organizations that will receive partner-scoped reports, contribute sightings, or operate inside a shared trust group. Treat the addition of a partner with the same care as adding a member — you are extending real operational visibility.
Connection states
| State | Meaning | Operational implications |
|---|---|---|
| Requested | One organization has asked to connect and the other has not yet accepted or declined. | Not usable for incident sharing. Visibility settings that depend on this partner have no effect yet. |
| Connected | The relationship is active and supports partner-oriented visibility decisions. | Reports scoped to "selected partners" or to a trust group containing this partner are shared per visibility rules. |
| Declined | The receiving organization rejected the request. | No sharing. A new request can be initiated later if circumstances change. |
| Revoked | A previously active relationship was intentionally ended. | Future sharing stops. Past shared records remain with the partner unless separately removed. |
Do not rely on a requested relationship for operational sharing until your team confirms readiness and the connection state. A reviewer who selects a partner before connection is established will not produce a shared record.
Relationship lifecycle
A healthy partner connection moves through five stages. Each one corresponds to specific actions in the Castlewatch interface.
- Vetting (offline). Confirm the partner organization is who they claim to be. Verify with a phone call, a regional coordinator, or an existing trusted partner.
- Request. Initiate the connection from your workspace, including any partner-specific notes.
- Receiving review. The receiving organization sees a pending request and either accepts or declines. Either side may include reviewer notes.
- Document tracking. Sign the template MOU and NDA if your operating posture requires them. Signature status and signer metadata are recorded against the relationship.
- Ongoing operation. Use partner messages for relationship-specific coordination. Re-confirm trust posture annually or after partner staffing changes.
MOU & NDA tracking
Castlewatch tracks template MOU and NDA signature status and signer metadata. This is not full negotiated document management. It is a practical record that the template documents have been acknowledged and signed for the relationship.
| Field | Use |
|---|---|
| Signer name | The full name of the individual who reviewed and signed. |
| Signer title | The role that authorizes them to sign on behalf of the organization. |
| Signer organization | Confirms which side of the relationship the signer represents. |
| Document version | Which template version was signed; preserves a useful audit trail when templates evolve. |
| Signed at | Timestamp the signature was recorded. |
- Preview the template before signing so the signer knows what is being recorded.
- Use signer name, signer title, signer organization, and document version fields consistently.
- Do not imply custom legal terms unless your organization has separately implemented and documented them.
- Re-sign after a material template update.
Partner messages
Secure partner messages preserve relationship-specific coordination notes. Use them for partner onboarding questions, relationship readiness, follow-up requests, and clarification about shared incidents. Messages are scoped to the partner relationship and visible only to authorized members of each side.
Use partner messages for
- Confirming who the operational point-of-contact is during an incident.
- Asking clarifying questions about a specific shared report.
- Coordinating regional patrol cadence or shared events.
Do not use partner messages for
- Internal team discussion — use incident comments or internal channels.
- Sensitive personal data that should not be retained.
- Time-critical alerts — use phone or your established emergency channel.
Trust groups
Trust groups organize connected partners into named coalitions for future incident visibility. A regional safety group, ministry network, or event-specific partner group can help teams avoid selecting the same organizations repeatedly.
- Create groups only from organizations that are already connected.
- Name groups in a way future administrators will understand (e.g., "East Metro Network", not "Tim's Friends").
- Review default sharing settings after adding or removing group members.
- Remove organizations from groups when the relationship or operating agreement changes.
- Avoid creating one group per partner — groups should represent shared operating context, not 1:1 relationships.
Common scenarios
Partner request from an organization you do not recognize
Do not accept based on the request alone. Confirm the requesting organization through a known regional coordinator or by direct phone contact. Decline if you cannot verify them — they can request again later.
Partner has changed leadership and may share less carefully now
Revoke the connection, log a partner message documenting the change, and let leadership re-establish trust with a fresh request after the transition stabilizes.
Setting up a regional coalition
Connect each member organization individually. Once every organization is in "Connected" state, create a trust group and add them. Update sharing defaults if most reports should reach the coalition by default.
Partner reports an incident that affects your campus
Open the incident detail page, comment with your local observations, and log a sighting if your team has corroborating evidence. Coordinate next steps through partner messages.
Frequently asked questions
Can a partner see all our reports?
Only reports whose visibility scope explicitly includes them — either through "selected partners" or a trust group they belong to. Origin-only reports are never shared.
What happens to past shared incidents if we revoke a partner?
Past shared records remain with the partner unless separately removed; future sharing stops. Revoke deliberately rather than as a quick fix — consider a partner message first.
Do we need MOU/NDA signatures to share?
Functionally no — the platform does not block sharing without them. Operationally, most teams require both before sharing partner-scoped incidents. Decide your posture and document it.
Can trust groups overlap?
Yes. The same partner can belong to multiple groups (e.g., "East Metro Network" and "Summer Event Coalition"). Sharing decisions evaluate all applicable groups.
Who can accept incoming partner requests?
Determined by the policy threshold for partner requests. Default is org admin. Tighten if external requests should always be reviewed by leadership.