SAKA can delete encrypted records from its internal database if a site's data retention policy demands it. For deleting ciphertext, the web service call requires four parameters:

When SAKA receives the request, it first verifies the credentials presented against its internal database or an optional LDAP directory server and then determines their authorization to request the deletion service by determining if they are a member of a DeletionAuthorized group. Note that if using LDAP, this group and its members must be created in the LDAP directory as a distinct task of the SAKA installation and configuration process; when using the SAKA internal database, this is performed automatically.

If the requester is authorized, SAKA searches its RDBMS for the token; if found, the record is deleted and the deletion logged. The deletion is replicated to other nodes of the cluster before a response is returned to the calling application indicating whether or not the deletion was successful.

Once deleted, the original plaintext cannot be returned to any calling application. While the key that encrypted the original plaintext might still be present in SAKA—potentially, to decrypt other records encrypted by the same key—a successful call to the deletion web service permanently removes the record from the database. Note that this does not imply that sites using SAKA may not have other copies of the encrypted record on their backup tapes. It remains the responsibility of the site to ensure compliance to its data retention policy.