Hi, George.
You have two things to accomplish: (1) make the
account's history available to the CS Reps to
facilitate anything they need to do in support of
the account; and (2) save enough information to make
it clear the company knows its own procedures, and
can demonstrate the historical accuracy and honesty
of the transaction.
I got kinda carried away (see below) and laid out
a suggestion that should satisfy both of the above.
The screen snap does not prove anything. It's all
the data, the logs, and the procedures surrounding
the interaction that really tell the story.
In lieu of saving a document "image", create a "report"
image that the CSRs would see instead. The members
would not have seen this exact report, but the report
would identify and isolate just what the members DID
see, plus related information:
* All statements that were presented for agreement,
with variable data filled in as it would have
appeared on the form. NOTE: This requires
a DOCUMENTED REVIEW PROCEDURE for the form itself,
to ensure that no text will be truncated or obscured
in the user's browser screen due to field size, frame
size, overlaying of text by graphics, inappropriate
background/foreground colors, the member's
(or browser's) refusal to run scripts or Java, etc.
The best safeguard against this is to generate nice
clean, simple HTML with sharply contrasting colors
and no fancy stuff; and to document with EACH update
of the agreement form that these standards were
adhered to.
* The server's local date and time when the agreement
was received, plus the user's account information
and IP address. This is specifically for correlation
with the site's server logs, which of course are also
being archived, in case an auditor ever wants to
trace a specific sign-up session.
* The full URL and other information that would correlate
with the design and contents of the screen that the
member saw. This should include some sort of version
coding, so you wouldn't have to make inferences about
when the transactions took place vs. when a particular
wording of the agreement was cut into production. Each
time the company changes the format or contents of the
agreement form, they will also (1) change the version
code and (2) save a snapshot of a sample screen.
If they can document this procedure, then it lends
credence to what the signing member saw, and it gives
the kind of transparency that is convincing in the
face of challenges.
In addition: The form that the user posts back
to your server should contain that same version
info as a data field, and the code processing that
form should CHECK the version against what had been
sent out in that session. This would close the loop,
so there would be no question as to what version of
the form the member was looking at. It would go both
ways as a hidden field, but the validation is to
confirm that a "sign-up" will not be accepted except
in response to the intended agreement form.
Saving the server's logs allows any investigation
to confirm the timing and progress of the user's
session, including when they logged in, what
IP address they were coming from, and how long
it was between having the agreement form presented
to them and their having posted back the signed
agreement.
Similar procedural consistency must also be
demonstrable for the member's log-in process, in
order to help confirm and support the identity of
the signing member. Just saying that you require
a member log-in doesn't cut it: you need to be
able to demonstrate that a respectable authentication
system was in effect for that specific historical
session.
IANAL, but I think this is the kind of logging and
procedural documentation that serious auditors would
look for in establishing good faith and an absence
of any deceptive practices. You probably should
review it with an auditor as well as with law-yuhs.
Have fun. (As you can see, I miss working!)
Vic
http://members.cox.net/vodhner/
(text/plain)