kmawКак обеспечить согласованность документа после его согласования и информации в БД, на основе которой он был сформирован. (администратор системы может всегда изменить какие-то записи в БД)

Из вашей постановки могу предложить такие варианты (все определяется вашими реалиями, задачами и сложностью):
1. Защитить сами исходные данные от изменения
Средствами СУБД (триггеры, или специфичные для вашей СУБД) - при условии, ограниченности прав администратора, не достаточной компетентности, ...

Собственные средства на базе криптографии. Проще говоря - шифровать данные

2. Обеспечить возможность проверки факта изменения и отката.

Зеркалировать данные, например, в момент подписания.
В зависимости от задач и возможностей это может быть просто другая БД/система, где у администратора нет прав. А может быть сертифицированная система неизменного хранения (ищите по Content Addressed Storage - но это такие деньги...).

"Подписывать" и исходные данные.

Рассматривать как эталон сам документ - только в нем нужно будет хранить все данные в структурированном виде (это довольно удобно сделано в том же Word 2007), хотя для структурированных документов я бы рекомендовал использовать InfoPath.

Основной момент в варианте 2 - когда проводить сверку/проверку подписей.

Как видите - особо хороших вариантов нет. Возможно есть смысл задуматься о разделении полномочий "админов"? Т.е. решить управленчески/методологически.

kmawЧто случится плохого - не известно.

Это плохо.
Серьезность вложений в безопасность зависит от серьезности возможных последствий.

Например, если самое серьезное, что вам грозит - это искажение остатков на складах, которое будет обнаружено уже в конце месяца, то городить огород просто нет смысла - не окупится.

kmawНо если случится такое - то надо как-то разрулить ситуацию: пользователь скажет я не виноват, админ скажет - я не виноват. кто виноват?

Собственно для этого и придумана ЭЦП. Вы фиксируете данные и авторство.

Только вопрос - какая разница кто виноват именно в искажении данных (кстати, почему если пользователь не виноват, то автоматически виноват администратор - или вы на столько уверены в безопасности вашей системы?). Вопрос, почему для совершения операций использовались "сырые" данные, а не подписанный документ (раз уж такой есть)?

iscrafmчто касается вопроса автора, то необходимо просто бизнес-процесс построить таким образом, чтобы редактирование документа, отправленного на подпись не допускалось.

Может я не правильно понял автора исходного сообщения, но мне показалось, что суть проблемы в том, что возможна рассинхронизация данных в некоторой учетной (или еще какой-то) системе и документами, которые генерируются на базе этих данных.

Т.к. документы согласуются и подписываются (криптографически защищаются), логично предпологать их неизменность (или хотябы фиксацию факта изменений). Однако далее, видимо (и вроде как логично) в работе используются исходные данные, которые от изменений не защищены.

Автор, собственно и опасается, что может сложиться ситуация, в которой пользователи системы согласуют документы с одними данными, а потом в работе окажутся совсем иные - случайно или преднамеренно.

Ну вот, пока я писал, автор уже сам подтвердил мои выводы