Written for the person who has to fill out the vendor review. Everything here is meant to be checked, not taken on trust.
Deployment model
- Where it runs
- On a Windows server inside your network, joined to your domain, managed and patched by you.
- What it is
- PowerShell 7 modules and a scheduled orchestrator. No agents on endpoints, no browser plugins, no cloud service in the path.
- Credentials
- Service accounts you create, scoped to the least privilege each connector needs, stored in your secret store or Windows credential vault. Tenure never receives them.
- Network
- Outbound only to the platforms it manages, on the same paths your admins already use. It makes no connection to Tenure or any third party.
- Data
- Employee identity attributes only. No member data is read, stored, or transmitted.
- Logging
- Every action, its target, timestamp, result, and the service account used, written locally and forwarded to your SIEM if you have one.
- Failure mode
- If Tenure is down, nothing is locked out. Your team falls back to the manual process, and the ticket queue shows what has not been run.
Access controls
- Dry-run approval before any change is made, by a named admin in your team.
- Position-to-access mappings are configuration you own and can review at any time.
- Implementation and support sessions happen over a screen share driven by your staff. Tenure does not hold standing remote access.
- Code is delivered signed, with a change log, and you decide when to apply updates.
For your vendor review
Because Tenure holds no credentials, no member data, and no standing access, most credit unions place it in a low-risk vendor tier. We supply the following on request:
- Completed vendor security questionnaire in your format
- Certificate of insurance: technology errors and omissions, and cyber liability
- Information security, incident response, and secure development policies
- Architecture and data-flow diagram for your environment
- Reference contact at a credit union running it in production
What the log gives an examiner
Access reviews ask two questions: was this person’s access removed, and can you prove when. The run log answers both per system, and it can be exported for a date range so a review covers every separation in the period rather than a sample.