Reviews and the vault audit log

Documentation is only useful while it is right. Tenvara helps with three things: reminding owners to review articles, one list of everything that runs out, and recording every look at a secret so you can answer "who has seen this password?" at any time, for you or for a customer's auditor.

Review dates and expiry#

Every article can have:

• An Owner: the person responsible for it.
• A Review by date, and Then every so many months if it should be checked regularly.
• An Expires date for articles that stop being true on a known day, such as a temporary process.

Set these in the side panel when you write or edit the article. See Knowledge base articles.

Reminders#

Each morning Tenvara sends the owner a notification for each article whose review date has arrived. If the article has no owner, the reminder goes to its author. Owners get one reminder per review date, not one a day.

Separately, owners are told seven days before an article expires.

What expiry does#

An expired article stays readable for staff, but it:

• Stops being suggested on tickets.
• Leaves the customer portal.

The article is marked Expired in lists, so it is obvious it needs replacing or retiring.

The Review due list#

Open Docs and choose Review due under Upkeep. It lists articles whose review is due in the next two weeks or overdue, and articles that are expiring or have expired, with the soonest first.

The Review column shows the state:

Filter by Where (the knowledge base or a customer), Owner, Status, Review or In the portal.

Reviewing an article#

1. Open the article from the list.
2. Read it and fix anything that is out of date. Editing and saving makes a new version.
3. Press Mark reviewed, or R.

If the article repeats its review, the next review date moves on by the interval, and it leaves the list until then.

Tip: Sort the list by Owner in a team meeting and let each person take their own. R marks the article in front of you reviewed, so working through a batch is quick.

Expirations#

Docs > Expirations is one list of everything that runs out, soonest first, read straight from where each date lives: article reviews and expiry dates, record dates that track expiry, domain registrations and SSL certificates, device warranties, Cyber Essentials certificates, contract terms, licence commitments, GDAP relationships, and from the vault, password changes that are due and certificates and API keys that expire.

• Coming up lists what runs out next; Expired lists everything that has already run out, however long ago.
• Choose how far ahead to look: 30 days, 90 days (to start with), 180 days or A year. What already ran out shows too, with a red edge.
• Filter by State (ran out, critical within 7 days, soon, later), Kind, Customer and Looked after by, and save views, export or print.
• Click a row to open where it is fixed: the article, record, domain, device, contract, licence, tenant or credential.
• The customer overview's Running out block shows one customer's.

Looked after by is the article's owner, the contract's account manager, or the customer's account manager or technical lead; for a credential, its owner.

Every Monday morning each person gets a Weekly expirations digest of what they look after that runs out soon or already has. People choose email or the in-app inbox in their notification settings, and Settings > Documentation, under Expirations sets what the page lists, the warning window and the digest.

Tip: In Docs > Record templates, a date field (or a table's date column) can be marked Tracks expiry with its own warning, so dates you keep in records, such as a broadband contract's end, show here too.

The vault audit log#

Open Docs and choose Vault audit log. It records who revealed, copied or changed which secret, when, and from which address and browser.

Each row shows:

A reveal made while working on a ticket carries that context, so the log shows what the person was working on as well as what they opened.

Filter by Who, What or Customer, or type in the filter box to search by person, credential or address.

Things to know about the log#

• It covers records too. Secret fields in records are in the vault, so revealing them is logged here in the same way.
• It survives deletion. Deleting a credential or a record keeps its audit entries. Removing a secret field from a template logs each secret it deletes.
• Administrators-only credentials stay private. Their entries are only visible to administrators.
• It is separate from activity. Reveals and copies never appear in the customer timeline or the general activity log, only here.
• Each credential has its own view. The Who has seen it table on a credential shows its part of the log.

Seeing the vault audit log needs the Manage level of the Credentials permission; your own company's lines need the same level of Our company credentials. See Roles and permissions.

Exporting the log#

Press Export on the vault audit log to download the lines that match your filters (period, customer, person and action) as CSV, or the newest of them as a PDF in the customer's branding. The export is itself in the audit log.

Credential access reports#

Docs > Access reports (or Access report on the audit log) is a report for a customer or their auditor: which of their credentials were revealed, copied or filled in, by whom, when and from which address.

1. Choose A customer and the customer (or Our company for your own).
2. Choose the period: Last month to start with, a year at most.
3. Read the totals, the breakdown By credential and By person, and every access with its address.
4. Press Download PDF for a copy in the customer's branding and language.

A customer's report never includes your own company's lines. Monthly customer reports can include a Credential access section too: tick it in the report template.

Using the log after someone leaves#

When a technician leaves, filter the log by Who for that person. Every credential they revealed or copied is listed, which is the list of passwords to change. Open each one from the log, change the password, and the Set entry records that it was done.

Self-hosted: the vault key#

On a self-hosted install, the keys that protect the vault are derived from the application key (APP_KEY). If you rotate the application key, the vault needs one extra step or secrets will not open:

1. Put the old key in APP_PREVIOUS_KEYS (comma separated) and set the new APP_KEY.
2. Restart Tenvara. Secrets still open with the old key.
3. Run the rekey command:

   php artisan docs:vault-rekey
   

   It rewraps every secret's key under the new application key without re-encrypting the secrets themselves, and reports how many it changed.
4. Once it reports nothing left under the old key, remove the old key from APP_PREVIOUS_KEYS.

Warning: Without the old key, secrets cannot be opened at all. Keep a copy of the application key somewhere safe, away from the server.

On hosted Tenvara this is looked after for you.