assurance - RE: [Assurance] RE: [confluence] InC-Assurance > Remote-Proofing Approaches
Subject: Assurance
List archive
- From: "Jones, Mark B" <>
- To: "" <>
- Subject: RE: [Assurance] RE: [confluence] InC-Assurance > Remote-Proofing Approaches
- Date: Fri, 10 Aug 2012 14:19:38 -0500
- Accept-language: en-US
- Acceptlanguage: en-US
Ok, so if the context is decisions in a Silver audit then this is an
understandable exercise in semantics. I never suggested that an auditor
would use 800-63 to perform a Silver audit.
-----Original Message-----
From:
[mailto:]
On Behalf Of Cantor, Scott
Sent: Friday, August 10, 2012 1:38 PM
To:
Subject: Re: [Assurance] RE: [confluence] InC-Assurance > Remote-Proofing
Approaches
On 8/10/12 2:29 PM, "Jones, Mark B"
<>
wrote:
>This all seems like an exercise in semantics to me. Google and
>InCommon have been approved by ICAM. ICAM uses 800-63 as one standard
>that is used to measure compliance. This suggests that ICAM is of the
>opinion that Google and InCommon are substantially compliant with
>800-63 or they would not be approved.
I really don't believe that 800-63 was a direct criteria in the approval of
Google. So I don't see how that's semantics, but since I don't have proof,
I'll just say that it's the basis of my opinion.
>I have yet to notice or be presented with a significant difference
>between the IAP and 800-63 yet there is enthusiastic effort to maintain
>that they are not the same. I feel like I am trying to argue that my
>car is maroon while everyone else insists that it is dark red. Why is
>there such resistance to being associated with 800-63?
Well, from a personal PoV, I have a lot of issues with it, but as I already
said, the reason they're so close is that unlike the Google case, there was a
very conscious mapping. But the bottom line is, unless Silver explicitly
references 800-63 for a requirement, there is nothing in 800-63 that should
be relevant to a decision by an auditor on compliance with Silver. If there
is, I would think it needs to get moved into Silver.
-- Scott
- Re: [Assurance] RE: [confluence] InC-Assurance > Remote-Proofing Approaches, (continued)
- Re: [Assurance] RE: [confluence] InC-Assurance > Remote-Proofing Approaches, Tom Scavo, 08/10/2012
- Re: [Assurance] RE: [confluence] InC-Assurance > Remote-Proofing Approaches, William G. Thompson, Jr., 08/10/2012
- Re: [Assurance] RE: [confluence] InC-Assurance > Remote-Proofing Approaches, Cantor, Scott, 08/10/2012
- Re: [Assurance] RE: [confluence] InC-Assurance > Remote-Proofing Approaches, William G. Thompson, Jr., 08/10/2012
- Re: [Assurance] RE: [confluence] InC-Assurance > Remote-Proofing Approaches, Cantor, Scott, 08/10/2012
- Re: [Assurance] RE: [confluence] InC-Assurance > Remote-Proofing Approaches, Ian Young, 08/10/2012
- RE: [Assurance] RE: [confluence] InC-Assurance > Remote-Proofing Approaches, Jones, Mark B, 08/10/2012
- Re: [Assurance] RE: [confluence] InC-Assurance > Remote-Proofing Approaches, Cantor, Scott, 08/10/2012
- RE: [Assurance] RE: [confluence] InC-Assurance > Remote-Proofing Approaches, Jones, Mark B, 08/10/2012
- Re: [Assurance] RE: [confluence] InC-Assurance > Remote-Proofing Approaches, Cantor, Scott, 08/10/2012
- RE: [Assurance] RE: [confluence] InC-Assurance > Remote-Proofing Approaches, Jones, Mark B, 08/10/2012
Archive powered by MHonArc 2.6.16.